How do I fix Eclipse CDT Error "Function 'isdigit' could not be resolved" with Android NDK?

Question

I am using Eclipse Indigo with an Android/NDK mixed project. I've added C++ nature and almost everything is working. Automatic builds work; that is, when I edit a file ndk-build is invoked and completes successfully - no build errors. Mouseover code assist works (the little window pops up with information about the function). If I place the cursor on an include line and press F3, a relevant header file open (not the one I would expect based on my configuration, but a relevant one - maybe a clue?).

If I select the following line in my .cpp file, it opens $NDKROOT/platform/android-3/arch-arm/usr/include/ctype.h:

#include <ctype.h>

(isdigit is defined in this file)

However, Eclipse insists that isdigit is not defined. I have read many posts suggesting that either the static analyzer or the indexer is to blame, but I've tried many of the suggested solutions to no avail.

If I add a line like the following, the error goes away and mouseover code assist for the function works:

extern int isdigit(int);

Again, this is not a linker error or a compiler error - ndk-build completes with no errors. This is something inside eclipse. Thanks for taking a look!

Edit: I now believe this to be a Code Analysis problem. A better solution is to edit the Code Analysis options to make "Function could not be resolved" be a warning instead of an error. That way you can see the warnings in Problems view, but continue to work. If the function is REALLY missing, the compiler will tell you! I also have a new theory, that the problem is with the Code Analyzer following symlinks, because all of the "missing" functions are in symlinked include files. Would love any input on this theory.

Answer 1

After spending several days working on problems like this, I developed the following recipe for dealing with issue.

I hope it helps you or others:

Summary: Usually, your problems in eclipse are due to eclipse configuration problems. The following assumes that your C++ code is building ok with ndk_build or ndk_build.cmd (on windows).

• No joy with eclipse juno (4.2) and CDT version 8.1. Use eclipse indigo (3.7)

• Make sure that you have the CDT for indigo installed and enabled (version 8.0X) by looking in the "install new software". It defaults to installed but not enabled on indigo on some downloads.

• When you are dealing with native code or android config for native code, make sure you are in the C++/C perspective in eclipse, not the java one. It is deceptive, but there is a only a subset of options available in Java perspective. You can be sure you are C++/C perspective if you see "C/C++ general" as a choice when you do "Project > Properties."

• The usual problem is that the indexer in C/C++-land thinks there are errors when there is not (e.g. building with ndk-build works ok, often you can see this in the console window even). This is caused by bad paths in the "Paths And Symbols" part of "Project > Properties > C/C++ General" on the first tab.

• To fix the problem, the primary tool is to right-click on the project, select "Index" and "Search for unresolved includes." This will tell what files it can't find--and these are typically not the ones that you have in your files with the little pink mark by them.

• To find the right file, search in your NDKROOT directory (where you installed NDK). A typical one to add is: ${NDKROOT}/platforms/android-9/arch-arm/usr/include or the right android-N for your android target. There are many copies of the standard include directories in the NDK because of multiple versions of android and copies of the C++ standard libraries.

Two big warnings

• The "unresolved includes" view in eclipse does not automatically update when you change the indexer configuration on the Properties > C/C++ General/Paths and Settings so be sure to run it again each time. Most views in eclipse do this update properly!

• Also the little red/pink error markers in the source code views in the eclipse editor don't automatically update either. You have to "touch" the file in some way for it discover that the error is now fixed.

Answer 2

I worked around this issue via the approach I suggested in my question and haven't been able to find a better way yet.