I'm a pretty newby when it comes to the android NDK, so here is my problem.
Whenever I build my native code, i only get arm v5 code, not v7, thats really my problem. My Android.mk file looks like this:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
APP_ABI := armeabi armeabi-v7a
LOCAL_MODULE := SignalProcessing
LOCAL_SRC_FILES := fir.c fourier.c fastmath.c
include $(BUILD_SHARED_LIBRARY)
As you can see, i have 3 native c files in there, when ever i run the ndk-build command, only 1 file appears in: libs/armeabi/libSignalProccsing.so. This is just the Armv5 file, where is the Armv7 file?
I've googled my ass off on this matter and can't find anything about it. The only info i can find is to ajust APP_ABI values, but ive tried that 10000 times. Ive even filled in nonsense values and i dont get an error on that, please help!
Regards,
Maarten
I found my answer. I need to put the line
APP_ABI := armeabi armeabi-v7a
In Application.mk NOT in Android.mk
Related
I tried to build the ndk and get error
/android-ndk-r9/build/core/prebuilt-library.mk:68: *** target pattern contains no '%'. Stop.****
my Android.mk code is :
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
OPENCV_CAMERA_MODULES := on
OPENCV_INSTALL_MODULES := on
#OPENCV_LIB_TYPE:=SHARED
include D:/Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
LOCAL_SRC_FILES := F_jni.cpp
LOCAL_C_INCLUDES += $(LOCAL_PATH)
LOCAL_LDLIBS += -llog -ldl
LOCAL_MODULE := f
include $(BUILD_SHARED_LIBRARY)
please help Until I resolve my problem.I'm really confused.I tried several ways and I could not solve my issue.
ndk-build invokes make which does not handle the : character in targets well. If your project resides on disk D:, too, then you can refer to OpenCV without the drive letter,
include /Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
Otherwise you can try
include //D/Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
include //localhost/D$/Books/Java/winx86_01Jan12/OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
If nothing helps, copy your OpenCV SDK such that you can use a relative path, e.g.
include ../../OpenCV-2.4.9-android-sdk/sdk/native/jni/OpenCV.mk
PS The source of your troubles is probably cygwin somewhere on the PATH. Since November 2011, NDK r7, ndk-build does not need cygwin. OpenCV made the reciprocate step short afterwards. Unfortunately, many developers still need cygwin for their daily work; furthermore, until recently, you still needed cygwin to run ndk-dgb (you have ndk-gdb-py.cmd now!). So my advice is to remove cygwin\bin directory from your PATH before you run ndk-build.cmd. You can easily do it in Project build properties if you use Ecliplse/ADT to build your native code.
I have an application which uses native libraries for various targets – ARMv6, ARMv6+vfp, ARM7+vfp, ARM7+Neon, ARM7 + Tegra as well as some universal libraries. My goal is to pack all the libraries into one .apk file so that I don’t have to distribute separate builds – I don’t care a much about the total .apk size.
Here is my Android.mk script – just an example but with enough info:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
TARGET_ARCH_ABI := armeabi
LOCAL_MODULE := prebuilt_arm_v6vfp
LOCAL_SRC_FILES := ../bin/libplayer_v6vfp.so
LOCAL_EXPORT_LDLIBS := ../libplayer_v6vfp.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
TARGET_ARCH_ABI := armeabi-v7a
LOCAL_MODULE := prebuilt_arm_v7n
LOCAL_SRC_FILES := ../bin/libplayer_v7n.so
LOCAL_EXPORT_LDLIBS := ../libplayer_v7n.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := player
LOCAL_SRC_FILES := some_cpp_sources...
LOCAL_LDFLAGS := -L$(LOCAL_PATH)/../bin
LOCAL_LDLIBS := -llog -lz -lm -lplayer_v7n -lplayer_v6vfp
LOCAL_ALLOW_UNDEFINED_SYMBOLS := true
include $(BUILD_SHARED_LIBRARY)
Now I have the following problem – it creates libs folder with armeabi and armeabi-v7a subfolders – that’s OK. But the content of both subfolders is the same, both contains libplayer_v7n.so and libplayer_v6vfp.so as well.
How can I assure each subfolder contains only a correct version of native library according to its eabi version?
EDIT 1:
As you can see, I link libplayer.so with both shared libraries, they have compatible interfaces. I wanted to select the correct library dynamically when loading in my Java wrapper after detecting the CPU type. But it seems it is not possible. Any idea how to choose the correct library dynamically? There must be a solution for such a common case.
EDIT 2:
It seems I can link my libplayer.so only with one library and have to select its correct version at runtime. But now the problem is how to store six native libraries of various versions but with the same name in the lib folder. Subfolders seem to be an obvious solution, but I am not sure it is possible. The other solution would be to deploy the correct library via the separate .apk as a plug-in, but that’s exactly I want to avoid..
Then do the following:
name architecture specific libraries with same name (for example: libplayer_arch.so) & put them in different directories.
link libplayer.so to libplayer_arch.so
write your Java code like this:
.
if (isArmv7())
{
System.loadLibrary("armv7/libplayer_arch.so");
}
else
{
System.loadLibrary("armv6/libplayer_arch.so");
}
System.loadLibrary("libplayer.so");
I have a program I am porting that links together multiple libraries when creating the executable. I have built all those libraries using the stand alone toolchain and using the standalone toolchain I am able to create an executable that works on an android device. So, it seems like the libraries I have built are functional. Now I am trying to incorporate those libraries with an app. So, in my android.mk I have something like this:
LOCAL_PATH := $(call my-dir)
ROOT_PATH := $(LOCAL_PATH)
include $(call all-subdir-makefiles)
include $(CLEAR_VARS)
LOCAL_PATH = $(ROOT_PATH)
LOCAL_MODULE := test-libs
LOCAL_STATIC_LIBRARIES := staticA
LOCAL_SHARED_LIBRARIES := sharedA sharedB sharedC sharedD
LOCAL_SRC_FILES := test-libs.c
include $(BUILD_SHARED_LIBRARY)
For each of the libraries, I have a Android.mk like this
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := sharedA
LOCAL_SRC_FILES := sharedA.so
include $(PREBUILT_SHARED_LIBRARY)
When I then build my project (in eclipse), I get this:
C:/ndk/android-ndk-r7b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.4.3/libgcc.a(unwind-arm.o): In function `__gnu_unwind_pr_common':
/cygdrive/c/ndk/android-ndk-r7b/build/core/build-binary.mk:314: recipe for target `obj/local/armeabi/libtest-libs.so' failed
/tmp/ndk-digit/src/build/../gcc/gcc-4.4.3/libgcc/../gcc/config/arm/unwind-arm.c:1237: undefined reference to `__cxa_call_unexpected'
Any thoughts on what is going wrong?
Also, the static library and one of the shared libraries have no dependencies on anything and if I only include them all is cool. One of my shared libraries only had a dependency on the static library. If I only include those, but when I include the others, which have dependencies on other shared libraries, this problem occurs.
Update 1: Ok it appears to be because the APP_STL setting in my Application.mk was being ignored. All I have in my Application.mk is:
APP_STL := gnustl_shared
If I copy over the libgnustl_shared.so and treat it like another prebuilt shared lib, my problem is gone. Any idea why the APP_STL is not working properly. Note, I could have screwed something up. I just upgraded to using 7b. Using gnustl_shared used to work for me with other apps. Rolling back to 7 doesn't fix it. I think I have messed something up in Eclipse. I use Eclipse (windows) with sequoyah.
It looks like the linker is giving you an error. What you should do is the following:
Add a LOCAL_LDLIBS under your LOCAL_MODULE := test-libs. Here you need to include all the libraries you link against when you compile your pre-compiled libraries. So for example:
LOCAL_LDLIBS := -lgnustl_shared -lgcc -llog -landroid -lstdc++
Basically you need to identify what library contains the function __cxa_call_unexpected. A quick google shows that it's probably in libstdc++. Make sure that you also link with this library when creating your pre-compiled libraries.
I'm thinking it might have something to do with exceptions support.
Are you using exceptions in your code and if so are you compiling with a runtime library that supports exceptions? (and compiling with exceptions on)?.
There is more on this in the CPLUSPLUS-SUPPORT and STANDALONE-TOOLCHAIN files in the ndk docs.
I've observed a similar problem when one of my projects which contains only C source files (*.c) references another project that contains a c++ file(*.cpp). Application.mk files for both projects had APP_STL := gnustl_shared in them. The ndk version is ndk7e.
The solution was adding an empty C++ file (dummy.cpp) to the project that contained only .c files. Supposedly ndk understood that this project should be linked against the gnustl_shared and the build succeeded.
I have an Android.mk file that compiles my NDK C code just fine:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := galib
LOCAL_SRC_FILES := galib.c tables-lr35-contam.c tables-lr35-perf.c
LOCAL_CFLAGS := -DTARGET_ANDROID=1
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
include $(BUILD_SHARED_LIBRARY)
I'd like to call the first source galib.cpp instead of .c because that's the name I need it to be when compiling it in the WPF environment. It really is just C code but to make a DLL I have to name it .cpp for it to handle the __declspec(dllexport) stuff properly.
However, when I rename it galib.cpp and change the .mk file to say the same and try to build it for Android, I get the error:
$ ndk-build
make: *** No rule to make target `/cygdrive/c/apk/adev/android/etold/jni/galib.c',
...needed by `/cygdrive/c/apk/adev/android/etold/obj/local/armeabi/objs/galib/galib.o'. Stop.
as though it still wants a .c file for some reason. I also tried "ndk-build -B" in case there's something left over from the .c build, but that results in the same error. Any idea why? Thanks!
I know that you asked that long time ago. But anyway - for other people like me:
I tackled into this problem too just now.
For some reason clean build doesn't do the job even when you change the sources list at LOCAL_SRC_FILES.
I had to navigate to \obj\local\armeabi\objs\ within the project and clean .o files manually.
After that it compiled fine.
I'm trying to build a simple Android application using NDK.
Here are the contents of my Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_LDLIBS := -llog
LOCAL_MODULE := myNDK
LOCAL_SRC_FILES := native.c
include $(BUILD_SHARED_LIBRARY)
And when I'm running ndk-build I get:
make: * No rule to make target
'/native.c', needed by
'/Users/ivan/Documents/workspace/TestNDK/obj/local/armeabi/objs/myNDK/native.o'.
Stop.
So the problem is obviously that make is searching the source files in the root directory and if I copy native.c to my root folder everything works perfectly.
The question is: what should I specify in my Android.mk to set the LOCAL_PATH to my working jni folder.
OK, I've solved my issue, and the reason was very strange:
the problem is in the first line
'LOCAL_PATH := $(call my-dir)____'
It had several spaces in the end (I've replaced them with '_'). If you remove them everything works just fine.
On Mac OS X using android-ndk-r9 64 bit, remove white spaces from the NDK path. That fixed the No rule to make target error for me
Not exactly an answer for OP, but I guess it can save others from wasting their time.
Another problem that I found that causes this error is that the
LOCAL_SRC_FILES := native.c
and
LOCAL_MODULE := native
use the same name. I'm not sure why this causes an error, as the code should be generated in different locations as native.o, native.od, and native. But, apparently it does.
I found this out while trying to compile hello.c to hello. Once I changed hello.c to main.c, everything compiled properly.
Make sure LOCAL_PATH is at the top of the Android.mk else it won't work due to GNU Compiler syntax
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
Also can have ifeq/endif prior to this if need the ndk-major-at-least shorten path or function defines
If there are any syntax error in Android.mk file, no rule to make target error will be there.
I had the same problem.
I have faced this issue when there is a spelling mistake in the root directory name.
Example:
My path should have been:
include $(phone-root-dir)/test/test.mk
but there is spelling mistake as shown
include $(lphone-root-dir)/test/test.mk
Once I corrected spelling mistake it worked fine.