Resolving the ‘unresolved inclusion’ error in Eclipse CDT for standard library headers of the Android NDK

Posted at 04 Dec 2014
Tags: c, cpp, eclipse, android, ndk

Java Native Interfaces (JNI) and the Android NDK are a nightmare to set up properly for development. For my first NDK experiments I didn’t care about features like nice syntax highlighting, auto-completion or interactive debugging. Too much of a hassle. But for bigger projects the described IDE features are crucial. Enter Setting up Eclipse for Android C/C++ Development and Debugging.


After clicking through a jungle of Eclipse dialogs, C/C++ syntax highlighting, auto-completion and debugging finally arrives to your 21th century IDE. However, you might find that standard C library functions or definitions will display an “unresolved symbol” error in the editor, although you include the correct headers, set the correct paths to the header files for either GNU C or GNU C++ (step 8 in Martin Hejna’s how-to), and although your native library compiles just fine when calling ndk-build from the command line. So although the compiler can successfully create your library and your application could be launched, Eclipse prevents this because the CDT code analysis tools think they found errors, because they are not able to resolve the path to the standard C header files. Rebuilding the index (under “Project > Properties > Index > Rebuild”) doesn’t work either. Of course, one work-around would be to disable all these errors and ignore them, but then again you wouldn’t need a fancy IDE any more.

The solution seems to be another option in the Eclipse CDT settings jungle. I came accross this stackoverflow answer and selected the “CDT GCC Built-in Compiler Settings” under “Project > Properties > C/C++ General > Preprocessor Includes > Providers” and it magically works.

If you spotted a mistake or want to comment on this post, please contact me: post(-at-)mkonrad(-dot-)net.
← “Android off-screen rendering using EGL pixelbuffers and OpenGL ES 2.0
View all posts
Some notes about OpenGL Textures, Mipmaps and Blackness” →