CODEWITHSUNDEEP
androidc++eclipseandroid-ndkeclipse-cdt
Dylan Lukes
Dylan Lukes

Reputation: 955

Eclipse-CDT fails to find stdlib symbols in NDK project

I am trying to write a simple Android application using the NDK and C++. Specifically, I'd like to use the gnustdc++ included with the newest version of the NDK (r7). The JNI library has compiled and worked perfectly fine as C, but now that I'm trying to introduce C++, I've run into some issues.

I have added ${NDK_ROOT}/sources/cxx-stl/gnu-libstdc++/include/ to my project's include paths, and the #includes inline are resolved. However, attempting to actually use any STL class (such as vector) results in Symbol 'vector' could not be resolved.

All of the standard C symbols imported from <stdlib.h> and such work as well, until I try to replace the #include with <cstdlib>. Then it fails with Function 'malloc' could not be resolved and so forth.

Oddly enough, adding the stlport headers (in ${NDK_ROOT}/sources/cxx-stl/stlport/stlport) fixes all of my issues. However I am linking in GNU C++, not STLPort, so this is an inconvenient and improper "solution" at best. It seems odd that these headers would work but the others would not. Is Eclipse failing to index or resolve the GNU C++ headers?

Android.mk

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := libfoobar-jni
LOCAL_SRC_FILES := foobar.cpp
LOCAL_LDLIBS := -llog -lGLESv2

LOCAL_C_INCLUDES := sources/cxx-stl/gnu-libstdc++/include/
LOCAL_CFLAGS := -g -std=c99

include $(BUILD_SHARED_LIBRARY)

Application.mk

APP_STL := gnustl_shared

Edit: I set up my project based on:

http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-development/

Upvotes: 8

Views: 9100

Answers (3)

David Karla
David Karla

Reputation: 89

I had this issue come up on windows due to the different path formats in cygwin, my prefered windows shell, and which uses pseudo unix style paths rather than windows. If you are having this problem, and you have cygwin floating around in your path, eclipse could be using it. Change the paths in Properties>C General>Paths and Symbols to be cygwin style rather than windows style (/cygwin/c/Android.... rather than C:\Android...) ... anyway, this worked for me.

Upvotes: 0

corbin
corbin

Reputation: 1556

Read this, it has the solution:

http://comments.gmane.org/gmane.comp.handhelds.android.ndk/14371

The summary, in case the link dies some day is this:

It's a bug in the gnustl_shared module declaration. Sorry about that, it will be fixed in the next release. In the meantime, you can manually change $NDK/sources/cxx-stl/gnu-libstdc++/Android.mk and replace the line that says:

LOCAL_EXPORT_LDLIBS := $(LOCAL_PATH)/libs/$(TARGET_ARCH_ABI)/libsupc++.a

with:

LOCAL_EXPORT_LDLIBS := $(call host-path,$(LOCAL_PATH)/libs/$(TARGET_ARCH_ABI)/libsupc++.a)

Upvotes: 3

Sandy Chapman
Sandy Chapman

Reputation: 11341

I know it's not a perfect solution, but at least it'll let you click "run" or "debug" through Eclipse:

  • Right click on your Android C++ project and select Properties.
  • Under C/C++ General, click "Code Analysis"
  • Switch to "Use project settings"
  • Switch any errors you're receiving due to using the vector class to be "warnings".

For me, the errors I've needed to switch so far are:

  • "Symbol is not resolved"
  • "Member declaration not found"
  • "Invalid template argument"
  • "Invalid arguments"
  • "Method cannot be resolved"

Like I said, it's not perfect and you might miss real errors due to this, but you still get the ability to usually select "Go To Declaration" and some syntax checking abilities, as well as the ability to launch your program. The ndk-build step will catch any real errors anyway, so it's really not a huge loss. Honestly, I'm not sure of the source of this issue. It's likely got to be an Eclipse bug.

Off topic but relevant: you can also use the ndk-gdb through eclipse. The tutorial is on the blog linked to the OP, but here's a direct link anyway.

Best of luck!

Edit (followup):

I've since figured out a way to get around this problem, at least on my box. The OP said that including the STLPORT headers worked for him. It didn't for me, at first. I had to destroy my Eclipse project and start fresh (for some reason, it wouldn't let me remove some include definitions). Adding STLPORT fixed some issues, but in ndk r7b, I was still getting weird errors (e.g. NULL was not defined even after including stddef). I ended up having to include the x86 headers too. These should largely overlap with the arm ones, however, it's useful to have the arm ones 'on top' in the include order.

So, if you've been running into the same issue as I was, add

$NDK_DIR/platforms/android-14/arch-x86/usr/include

to your list of eclipse includes as well.

Upvotes: 2

Related Questions