I'm trying to wrap some functions of a c-library (OpenAL-MOB) in order to use them in my Android application.
I think that my functions aren't correctly exported.
Steps I've taken:
I've made a java class with the functions I would like to use in my Android application,
Created stubs by using javah and javac (I haven't changed any class names or package names after doing this),
Added the wrapper files to the Android.mk
Build an .so library (with ndk-build)
Copied the .so file to the libs/armeabi-folder of my android project
Loaded the library in my android code and called a native function -> unsatisfiedinkerror.
When I try to use the library in my android code, I am able to load the library, but it cannot find my wrapped functions.
System.loadLibrary("openal"); // Works
OpenAlConnector.init(); // My wrapped function throws an unsatisfiedlinkerror
I think that my functions aren't actually exported.
To add my wrapper functions, I've modified the Android.mk that was already present in the OpenAL-MOB project. I didn't get any errors during the build. The only thing I did, was adding 2 files (.c created by javah and a helper class) to the end of LOCAL_SRC_FILES.
Android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../include $(LOCAL_PATH)/../../OpenAL32/Include $(LOCAL_PATH)/../../mob/Include $(LOCAL_PATH)
LOCAL_MODULE := openal-static
LOCAL_SRC_FILES := ../../Alc/ALc.c ../../Alc/alcConfig.c ../../Alc/alcDedicated.c ../../Alc/alcEcho.c ../../Alc/alcModulator.c ../../Alc/alcReverb.c ../../Alc/alcRing.c ../../Alc/alcThread.c ../../Alc/ALu.c ../../Alc/backends/loopback.c ../../Alc/backends/null.c ../../Alc/backends/opensl.c ../../Alc/backends/wave.c ../../Alc/bs2b.c ../../Alc/helpers.c ../../Alc/hrtf.c ../../Alc/mixer.c ../../Alc/mixer_c.c ../../Alc/mixer_inc.c ../../Alc/mixer_neon.c ../../Alc/mixer_sse.c ../../Alc/panning.c ../../mob/alConfigMob.c ../../OpenAL32/alAuxEffectSlot.c ../../OpenAL32/alBuffer.c ../../OpenAL32/alEffect.c ../../OpenAL32/alError.c ../../OpenAL32/alExtension.c ../../OpenAL32/alFilter.c ../../OpenAL32/alListener.c ../../OpenAL32/alSource.c ../../OpenAL32/alState.c ../../OpenAL32/alThunk.c openalwrapper.c org_vansina_openal_OpenAlConnector.c
# set the platform flags
ifeq ($(APP_ABI),x86)
LOCAL_CFLAGS += -D HAVE_SSE
else
LOCAL_CFLAGS += -D HAVE_NEON -mfloat-abi=softfp -mfpu=neon -marm
endif
include $(BUILD_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := openal
LOCAL_STATIC_LIBRARIES := openal-static
include $(BUILD_SHARED_LIBRARY)
I've used NM to see which functions were exported (nm.exe -D libopenal.so). This was the result:
00002004 A __bss_start
U __cxa_atexit
U __cxa_finalize
00002004 A _edata
00002004 A _end
I'm not sure if I'm correct, but it seems that my functions are missing.
Does anyone have an idea what I can do or check? Is there a problem in my .mk file?
I'm try to wrap this library for some days now and I'm getting quite desparate. Any help is very much appreciated!
Edit:
I believe that it has something to do with building the library as a static first and then as a shared library. It seems that all the symbols get lost if I create a shared lib like that. Can someone give me additional info about this?
Related
I have an NDK project where I build the shared libraries using the cross-compiler and standard gnu make utils. That is done with a separate script. But for the purpose of using the libraries in my project, I would like my Android.mk process to call my script to generate the shared library if it hasn't already been built, and then have Android.mk wrap it using the PREBUILT_SHARED_LIBRARY process.
Currently, if I run my script offline to generate libmy_so.so, then the following makefile will work. However, if I don't run the script explicitly first, I get the following error:
Android NDK: ERROR:/path_to_project/Android.mk:my_module: LOCAL_SRC_FILES points to a missing file
and my script is never called, so the make process is failing before even trying to resolve the dependency.
include $(CLEAR_VARS)
LOCAL_MODULE := my_module
LOCAL_SRC_FILES := libmy_so.so
LOCAL_EXPORT_CFLAGS := # some stuff
LOCAL_EXPORT_LDLIBS := # some stuff
$(LOCAL_PATH)/libmy_so.so:
echo "generate file"
$(shell run_script_that_creates_libmy_so.so)
include $(PREBUILT_SHARED_LIBRARY)
Is there a clean solution to this? I am even ok with running the script automatically as a preprocessing step (I can always have my script quietly exit if the file exists already), but I have not found an incantation that allows the LOCAL_SRC_FILES variable to point to a non-existent file. I have considered placing a dummy libmy_so.so to start, but that is an ugly hack.
Found a hack -- better way?
I found a hack. The makefile prebuilt-library.mk in the NDK contains the following lines:
ifndef prebuilt
$(call __ndk_info,ERROR:$(LOCAL_MAKEFILE):$(LOCAL_MODULE): LOCAL_SRC_FILES points to a missing file)
$(call __ndk_info,Check that $(prebuilt_path) exists, or that its path is correct)
$(call __ndk_error,Aborting)
#endif
I created a copy of this file (and prebuilt-shared-library.mk to which I reference my copy of prebuilt-library.mk) and commented those lines out to stop the error. Then the trick is to make some target that is evaluated first depend on the file I want to generate. After digging through the .mk scripts in the NDK, I found that libraries serves the purpose. By adding libraries: $(LOCAL_PATH)/libmy_so.so to Android.mk, it will finally do what I want.
include $(CLEAR_VARS)
LOCAL_MODULE := my_module
LOCAL_SRC_FILES := libmy_so.so
LOCAL_EXPORT_CFLAGS := # some stuff
LOCAL_EXPORT_LDLIBS := # some stuff
$(LOCAL_PATH)/libmy_so.so:
echo "generate file"
$(shell run_script_that_creates_libmy_so.so)
libraries: $(LOCAL_PATH)/libmy_so.so
include /path/to/my/mk/files/prebuilt-shared-library.mk
This is obviously less than ideal as I would like to make sure my makefiles mature with newer versions of the NDK, but it does the trick. Still interested in more elegant solutions.
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.
Following is my MAKE file for the source that i'm compiling with the build AOSP
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES:= abc.c
LOCAL_MODULE:= abc
LOCAL_FORCE_STATIC_EXECUTABLE := true
LOCAL_STATIC_LIBRARIES := libc
LOCAL_MODULE_PATH := $(TARGET_OUT_OPTIONAL_EXECUTABLES)
LOCAL_MODULE_TAGS := debug
LOCAL_C_INCLUDES += \
$(LOCAL_PATH)/../../../external/sqlite/dist \
$(LOCAL_PATH)/../../../external/sqlite/android
LOCAL_SHARED_LIBRARIES := \
libsqlite \
libsqlite3_android
include $(BUILD_EXECUTABLE)
here, in the source abc.c i'm trying to use the functions declared in sqlite3.h. When i'm trying to build the android source it is returning error
no rule libsqlite3_android.so to make target abc.so
i want to link the sqlite library to my source file.
Plz help me to find where i'm going wrong and how can i solve the problem.
First, make sure you have built SQLite3 before. (You should build the whole project before add any new stuff or customize any code)
Second, make sure you are build the same target product when you build the SQLite3. (Make sure you have select the correct menu when you do 'lunch').
Last, make sure the SQLite3 objects is in the target folders. YOURANDROIDROOT/out/target/PRODUCTNAME/system/symbols...
In fact, you shouldn't have to link with libsqlite3_android library.
According to the AOSP libsqlite makefile (external/sqlite/android/Android.mk), libsqlite3_android is a STATIC library which is included in the libsqlite dynamic library (external/sqlite/dist/Android.mk).
So linking with libsqlite should be enough.
Very simple question, hoping for a very simple answer. I've been looking at a lot of people's android.mk files and have noticed this line. I had no documentation on it within my NDK's docs (at least find . -name "*.txt" | xargs grep "LOCAL_EXPORT_C_INCLUDES" came up with nothing). This was the only documentation I've read on it...goes way over my head...
Part 2: Am I correct in my assumption that I will need this line to use a pre-built shared library with another module? Thanks guys (and gals)
III. Exporting headers for prebuilt libraries:
The example above was called 'naive' because, in practice, the code in
foo-user.c is going to depend on specific declarations that are normally
found in a header file distributed with the prebuilt library (e.g. "foo.h").
In other words, foo-user.c is going to have a line like:
include < foo.h >
And you need to provide the header and its include path to the compiler
when building the foo-user module.
A simple way to deal with that is to use exports in the prebuilt module
definition. For example, assuming that a file "foo.h" is located under
the 'include' directory relative to the prebuilt module, we can write:
`include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := libfoo.so
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)`
The LOCAL_EXPORT_C_INCLUDES definition here ensures that any module that
depends on the prebuilt one will have its LOCAL_C_INCLUDES automatically
prepended with the path to the prebuilt's include directory, and will thus
be able to find headers inside that.
URL: http://www.srombauts.fr/android-ndk-r5b/docs/PREBUILTS.html
The following explanation for the LOCAL_EXPORT_* variables in ANDROID-MK.html in the docs folder of the r6 NDK:
LOCAL_EXPORT_CFLAGS
Define this variable to record a set of C/C++ compiler flags that will
be added to the LOCAL_CFLAGS definition of any other module that uses
this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES.
For example, consider the module 'foo' with the following definition:
include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_CFLAGS := -DFOO=1
include $(BUILD_STATIC_LIBRARY)
And another module, named 'bar' that depends on it as:
include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_CFLAGS := -DBAR=2
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)
Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when
building bar.c
Exported flags are prepended to your module's LOCAL_CFLAGS so you can
easily override them. They are also transitive: if 'zoo' depends on
'bar' which depends on 'foo', then 'zoo' will also inherit all flags
exported by 'foo'.
Finally, exported flags are not used when building the module that
exports them. In the above example, -DFOO=1 would not be passed to the
compiler when building foo/foo.c.
LOCAL_EXPORT_CPPFLAGS
Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.
LOCAL_EXPORT_C_INCLUDES
Same as LOCAL_EXPORT_CFLAGS, but for C include paths.
This can be useful if 'bar.c' wants to include headers
that are provided by module 'foo'.
I'm trying to create a shared library that links to another shared library.
Here is my main module Android.mk:
TOP_LOCAL_PATH := $(call my-dir)
include $(call all-subdir-makefiles)
LOCAL_PATH := $(TOP_LOCAL_PATH)
include $(CLEAR_VARS)
LOCAL_CPP_EXTENSION := cpp
LOCAL_C_INCLUDES := $(LOCAL_PATH)/include/ $(LOCAL_PATH)/lib/include
LOCAL_MODULE := SightCore-jni
LOCAL_SRC_FILES := SightDemo.cpp SightCore-jni.cpp
LOCAL_SHARED_LIBRARIES := SightAPI
LOCAL_LDLIBS = -llog
include $(BUILD_SHARED_LIBRARY)
I also have the prebuilt shared library in ./lib directory with its own Android.mk file:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := SightAPI
LOCAL_SRC_FILES := libSightAPI.so
LOCAL_C_INCLUDES := $(LOCAL_PATH)/include
include $(PREBUILT_SHARED_LIBRARY)
The SightCore-jni.cpp source file is the jni interface to the shared library and is loaded using the command
System.loadLibrary("SightCore-jni");
During the ndk-build process I get no compilation or linkage errors.
When I try to run the application and access one of the native methods I get the UnsatsfiedLinkError.
I noticed that if disable the references to the SightAPI in my jni code and put a typo to the LOCAL_STATIC_LIBRARIES := SightAPI line, The build is successful and there is no UnsatisfiedLinkError.
This mean that the jni code I have is good (I'm actually sure it is ok...)
So the observation is as follows:
If I compile the shared library with the prebuilt shared library I get a corrupted .so file.
If I compile the same ndk project without linking to the prebuilt shared library there is no problem loading the shared library from the java side.
Please help me out if you can.
Thanks in advance,
Ita
Found the issue.
Apparently the ndk build system doesn't automatically load referenced shared libraries, even if they are declared in your Android.mk.
I had to call on System.loadLibrary(SightAPI) & System.loadLibrary("SightCore-jni") in order to solve this issue. I would have expected that the only library to load would have been the main library SightCore-jni.
Well..I guess the moral is If you want something done, do it yourself :)
+1 to Roy Samuel for his effort and correct instincts.
I hope this helps anyone.
Cheers
Have you made sure that the cpp function name, that you'd like to use over JNI, is corresponding to the package name of the Java wrapper class where System.loadLibrary("SightCore-jni"); is present?
e.g. If you would like to use the C function, myFunction in the java layer, and suppose your JNI wrapper class is in the package com.my.package.sightcore,
then your C code function name should be like this :
JNIEXPORT JNICALL Java_com_my_package_sightcore_myFunction(JNIEnv * env, jobject thiz, ...)
If you are running your app on your device,
See if the API levels, and hence, the sdk release matches to your device's android version (API level).
Hope this helps. Let me know if you need more clarifications...
This happened to me, and the solution for me was to make sure I was including the proper file libgnustl_shared.so and not libc++_shared.so after I switched compilers. So, just making sure either one of these files is the correct one for your build, and making sure it's been updated with the latest, you shouldn't get this issue any longer.