Eclipse compiles successfully but still gives semantic errors
Solution 1
In your selected project preferences within the Eclipse environment, go to C/C++ General -> Code Analysis -> Launching. Make sure that both check boxes are unchecked. Close and reopen the project or restart eclipse and rebuild the project.
Solution 2
Since indexing for Android native code on Eclipse is incomplete, I managed to enable indexing in my NDK projects the following unintuitive way, it should work whether you use ndk-build
or plain make
or even cmake
. I'm using Kepler but it should work on older versions too.
Get your toolchain right
- Right click on project ->
Properties
->C/C++ Build
->Tool Chain Editor
-> UncheckDisplay compatible toolchains only
. - In the same window, set
Current toolchain
toLinux GCC
. - In the same window, set
Current builder
toAndroid Builder
if you're usingndk-build
, set it toGnu Make Builder
otherwise (this step may be wrong, sorry in advance if it is). - Right click on project ->
Properties
->C/C++ Build
->Build Variables
-> Make sureBuild command
reads the correct command for your project; if it's not, uncheckUse default build command
and correct it (it may bendk-build
ormake -j5
that you want). If you build the native code in a separate terminal, you can skip this step.
Make a standalone toolchain, it's probably the cleanest way to get STL sources in one place
- Go to the NDK root directory.
-
Run the following (tweak the settings according to your liking). Add
sudo
if you don't have write permissions to the--install-dir
because the script fails silently../build/tools/make-standalone-toolchain.sh \ --platform=android-14 \ --install-dir=/opt/android-toolchain \ --toolchain=arm-linux-androideabi-4.8
This is assuming that you use GNU-STL. If you use another C/C++ library, you will need to tweak the above command, and probably also the include paths in the next command.
Add the necessary include paths to your project
-
Right click on project ->
Properties
->C/C++ General
->Paths and Symbols
-> Go to theIncludes
tab -> SelectGNU C++
fromLanguages
-> ClickAdd
and add the following paths (assuming you installed the standalone toolchain to/opt/android-toolchain
):/opt/android-toolchain/include/
/opt/android-toolchain/include/c++/4.8/
/opt/android-toolchain/include/c++/4.8/arm-linux-androideabi/
/opt/android-toolchain/lib/gcc/arm-linux-androideabi/4.8/include/
/opt/android-toolchain/include/c++/4.8/backward/
/opt/android-toolchain/lib/gcc/arm-linux-androideabi/4.8/include-fixed/
/opt/android-toolchain/sysroot/usr/include/
-
Here, you can add every include path you want. In fact, I have my OpenCV built for Android and installed in the standalone toolchain, so I have the following include there:
/opt/android-toolchain/sysroot/usr/share/opencv/sdk/native/jni/include/
Now, the indexing should work. You should also be able to run ndk-build
(or make
if that's your build method) and then deploy your project to your device inside Eclipse.
Why?
Android native development on Eclipse is incomplete since the indexing doesn't work out of the box. This is due to having to support multiple architectures (ARMv7, Intel etc.), multiple STL options, multiple Android versions etc. This is why you have the bare make
based ndk-build
and the whole NDK structure, and this is also why NDK development is very unclean and few large volume native Android projects exist.
A big Android project is OpenCV where they had to develop a 1500 odd line CMake script to get it to compile for Android properly. At some point, they tried to export that script as a CMake based build system for Android but it couldn't keep up with the changes in the NDK system and was abandoned. This support should have been inside NDK itself.
The default NDK build system should have been standalone toolchain only, with all different architectures/C++ libraries having their own toolchains at the cost of storage space but with the advantage of cleanness, intuitiveness and good practice. Then you can incorporate any standard cross-compilation system that is also used elsewhere, is tested and is well-known, e.g CMake. You can, and in my opinion you should, do that with the NDK's make-standalone-toolchain
command as shown above. But in the end, this is only my opinion. If you feel comfortable enough with ndk-build
then go ahead.
Solution 3
It's actually quite hard to say what is the problem. Here are some advices:
- Try to import and build
hello-jni
(it is located injni
'ssamples
folder). If it runs without problems than problem is with linking OpenCV to your project. - It seems that you forgot to update
android-ndk
location inproject properties -> c/c++ build -> environment
. Here's link to problem Issue with build Android NDK project. - Build from console your project (
ndk-build -B
), delete all errors in Eclipse manually (inProblems
view select all errors and just click delete) and try to run project now. Sometimes this "hack" helps me to run project. - Close Eclipse and delete folder
path-to-your-workspace/.metadata/.plugins/org.eclipse.cdt.core
(backup it first).
JonasVautherin
Updated on July 09, 2022Comments
-
JonasVautherin almost 2 years
NOTE: it apparently is a recurrent question on StackOverflow, but - for what I have seen - either people never find a way or their solution does not work for me
The problem:
I am using Eclipse Juno ADT. Everything was working fine until I tried to update the NDK. I replaced my
ndk
folder (that was thendk-r8d
) by the new version (i.e.ndk-r8e
) and, in myPaths and Symbols
configuration, I changed the includes to go from g++ 4.6 to 4.7.It seemed to break my index: I could compile my code, but Eclipse was giving semantic errors, exactly like in [1] and [2]. The errors mainly come from symbol used by OpenCV4Android, such as
distance
,pt
,queryIdx
andtrainIdx
.When I tried to backup to my old configuration, the index was still broken! I cannot find a way to change this.
What I have tried
- Clean up the project
- Rebuild, refresh, and all the other options in the "Index" submenu (when "right-clicking" on the project)
- Disable / enable the indexer in the preferences
- Verify that symbols such as
trainIdx
only appear in my OpenCV4Android include in thePaths and Symbols
section. - Change the order of my includes in the
Paths and Symbols
section. I basically tried to put the OpenCV include in the beginning and in the end.
Some observations
What is not working
I assume that it is the CDT index because of the following:
- In command line, I can build my project using
ndk-build clean
andndk-build
. - When I start Eclipse, I have no error until I open a C++ file (from the
jni
folder). - I can always build the project, but as long as I have opened a C++ file, I can't run the application anymore because of a lot of
Field '<name>' could not be resolved.
- If I don't open the C++ files, Eclipse doesn't report any error and can build and deploy the Android application successfully.
Interesting fact
The following code reports errors on
line
,queryIdx
,pt
:cv::line(mRgb, keypointsA[matches[i].queryIdx].pt, keypointsB[matches[i].trainIdx].pt, cv::Scalar(255, 0, 0, 255), 1, 8, 0);
If I write it as follows, it works:
cv::DMatch tmpMatch = matches[i]; cv::KeyPoint queryKp = keypointsA[tmpMatch.queryIdx]; cv::KeyPoint trainKp = keypointsB[tmpMatch.trainIdx]; cv::line(mRgb, queryKp.pt, trainKp.pt, cv::Scalar(255, 0, 0, 255), 1, 8, 0);
It is not that all of the OpenCV functions are unresolved: only
pt
,queryIdx
andtrainIdx
are.Any comment will be really appreciated.
-
JonasVautherin almost 11 yearsThanks for your help. I'll try
1.
tomorrow. For2.
, I have already updated it. I am currently using3.
to run the project, but I need to do this every time because the same errors come back. I think I have already tried4.
, but I will try again tomorrow! -
JonasVautherin almost 11 years
4.
did not work. For1.
, I have an error inhello-jni.c
:Method 'NewStringUTF' could not be resolved
. Any new idea? -
JonasVautherin almost 11 yearsMore interestingly, I installed a new version of Eclipse-ADT to import my project and it had the same errors. I then tried to import
hello-jni
in this new Eclipse and it has the very same error. Is it possible that my problem is linked to my Ubuntu? Everything was working fine during the last few months though... -
Alex Cohn almost 11 yearsYes, the on-the-fly code analyzer for Android gcc in Eclipse seems to be not mature yet.
-
ArtemStorozhuk almost 11 yearsDoes compiler find
jni.h
? If yes, does it containNewStringUTF
function? -
JonasVautherin almost 11 yearsThe project compiles successfully. When I
Ctrl + Click
onjni.h
in the includes, I go to the file and it contains theNewStringUTF
function. -
ArtemStorozhuk almost 11 yearsI see only one possible solution: re-installation of Eclipse. I recommend you to download it directly from Android site.
-
JonasVautherin almost 11 yearsThat's another interesting point: by re-installing Eclipse and importing my project again, I came with the exact same problem...
-
ArtemStorozhuk almost 11 yearsEven
hello-jni
doesn't run? -
JonasVautherin almost 11 yearsPrecisely. Is there therefore something common between my old Eclipse and the freshly-installed one that might have been altered?
-
JonasVautherin almost 11 yearsI gave you the bounty to thank you for the time you spent on my problem. But any more comment would be greatly appreciated =).
-
ArtemStorozhuk almost 11 years@JonesV thanks for that :) I think that Android Studio won't have such problems.
-
JonasVautherin almost 11 yearsI hasn't indeed, since there's no NDK integration yet... =)
-
ArtemStorozhuk almost 11 years@JonesV, yes I said "won't have". This is Android IDE from Google at it will obviously have it. Read this.
-
JonasVautherin almost 11 yearsThat's not a solution per se, but I had to do this eventually.
-
Alex Cohn about 10 yearsI guess that the main raison d'etre of Android.mk and the whole ndk-build system was that it was cut out of the Android system tree. At first, Google didn't think people would need C/C++ for their apps at all, only as system libraries. Later, they provided NDK, but it's still contaminated with tools that are only relevant for system tree build.
-
Ayberk Özgür about 10 yearsThat makes sense. However, I find that seeing C++ support non-essential in the beginning is just naive. Take games for example, it is obvious that they are a big part of the mobile application world and they are practically %99 native code. There are probably other applications out there (e.g that is into image processing or uses visual effects) that are similar. So in the end, they should have provided robust and easy support for native development.
-
Alex Cohn about 10 yearsWell, NDK circa '14 is much, much more robust, feature-rich, and easy than 3 years ago. I should say that I cannot agree with your preference to standalone toolchain. It's perfect to port huge existing make-based projects, but it does not answer the need to compile for arm/mips/x86, etc. I find that for homegrown projects, it pays off to set up the
Android.mk
files hierarchy and enable quick and easyndk-build
. BTW, there is a very helpful CMake adaptation for Android NDK. It does use standalone toolchain. -
Ayberk Özgür about 10 yearsI can understand the desire to build simultaneously for multiple architectures, but the great majority of Android devices are ARMv7 with Intel entering the field just recently. In the worst case, I would rather use two standalone toolchains for ARMv7 and x86 along with my already CMake enabled project (that I can compile for the host or any other cross-platform target I want without changing a single line in my code/scripts) and neglect all other architectures (e.g MIPS or ARMv5 which is practically obsolete now) than using
ndk-build
and its Makefiles that is ancient technology by itself. -
Ayberk Özgür about 10 yearsNot to mention that I will prevent my APK from bloating with MIPS native libraries that will eventually run on 5 devices total when deployed. That is what most app developers are doing (forum.xda-developers.com/showthread.php?t=1385493) and I completely understand and support their decision.
-
Ayberk Özgür about 10 yearsOn the other topic, that CMake adaptation is the one I talked about in the original answer: It is exported from the OpenCV Android CMake script and the last commit was on 2012. The original script (can be found in the OpenCV repo) has evolved and developed much since that time. But a similar (but much simpler) functionality can be achieved with a 5 line CMake toolchain script that sets your sysroot.
-
M. Usman Khan almost 10 yearsits a solution "for now"
-
Cameron Lowell Palmer over 9 yearsGreat reason to simultaneously build is ARM, x86 for simulator and device. You could use ARM for both, but then the emulator is so slow you end up always on device.
-
Shmil The Cat over 9 years@AlexCohn +1 may God bless you, this issue drove me crazy for a complete day
-
Ayberk Özgür over 9 yearsBy the way, on an unrelated topic, do yourselves a favor and switch to vim+YCM for c/c++ development. Eclipse is really not a good tool for that.