Crystax NDK linker error - android

I'm trying to get working Crystax NDK example and have the following error (I've made up PATH/TO/MY/CRYSTAXNDK/ of course):
$ ndk-build APP_ABI=armeabi-v7a
[armeabi-v7a] Executable : test-boost
PATH/TO/MY/CRYSTAXNDK/crystax-ndk-10.3.1/sources/boost/1.59.0/include/boost/archive/detail/oserializer.hpp:88: error: undefined reference to 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::save(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
Actually, this example is a bit outdated and I've already solved this error:
Android NDK: ERROR:PATH/TO/MY/CRYSTAXNDK/crystax-ndk-10.3.1/sources/boost/1.59.0/Android.mk:boost_atomic_static: LOCAL_SRC_FILES points to a missing file
Android NDK: Check that PATH/TO/MY/CRYSTAXNDK/crystax-ndk-10.3.1/sources/boost/1.59.0/libs/armeabi-v7a/gnu-/libboost_atomic.a exists or that its path is correct
by adding NDK_TOOLCHAIN_VERSION=4.9 into Android.mk.
I've also replaced $(call import-module,boost/1.57.0) with $(call import-module,boost/1.59.0) to call actual version of Boost library.
So, my Android.mk looks as following:
# Android.mk
LOCAL_PATH := $(call my-dir)
NDK_TOOLCHAIN_VERSION = 4.9
include $(CLEAR_VARS)
LOCAL_MODULE := test-boost
LOCAL_SRC_FILES := test.cpp gps.cpp
LOCAL_STATIC_LIBRARIES := boost_serialization_static
include $(BUILD_EXECUTABLE)
$(call import-module,boost/1.59.0)
My crystax-ndk directory is in a system path. I understand that the cause of my problem is that NDK linker is unable to find proper Boost libraries. But I don't know how to configure it in such a way that it will automatically choose libraries depending on the target architecture.
Please help me to figure out the configuration of the linker!
Thanks.

This is bug. Shortly speaking, libboost_serialization.so was built with GNU libstdc++ v5, but when you call ndk-build, it link final binary with GNU libstdc++ v4.9, which is binary incompatible with GNU libstdc++ v5 (specifically, std::basic_string; if interested, please look here for details).
This is fixed by a7c363377 and will be included to the next bug-fix release (10.3.2). In the meantime, you can apply that patch manually on your crystax-ndk-10.3.1 file tree to solve the problem.

I ran into the same problem following the CrytaX blog tutorial. I fixed it by adding the following
# Application.mk
APP_ABI := all
NDK_TOOLCHAIN_VERSION := 5
APP_PLATFORM := android-19
The 2nd line fixed the ndk-build Boost gcc lib path error. The 3rd line fixed the "only position independent executables" problem when invoking the executable.

Related

Linker errors with external NDK library that needs 'cpufeatures'

I'm trying to build and link freeimage to an android project. I'm close but I'm tripping up on some linker errors from that library.
I'm using this repo: https://github.com/jamcar23/FreeImage-Android/blob/master/jni/freeimage/Android.mk
Freeimage uses the internal NDK library 'cpufeatures' to use xeon chipset features. In the project's 'android.mk', there's a reference to the cpufeatures library:
LOCAL_STATIC_LIBRARIES := cpufeatures
and my library, which statically links to this one, also includes cpufeatures in its LOCAL_STATIC_LIBRARIES statement in that project's android.mk:
LOCAL_STATIC_LIBRARIES := tinyxml freetype2 bullet freeimage cpufeatures
also in my android.mk, I link freeimage like this:
#####FREEIMAGE_LIBRARY_DECLARATION##########
include $(CLEAR_VARS)
LOCAL_PATH = $(TPLIBROOT)/FreeImage-Android
LOCAL_MODULE := freeimage
LOCAL_EXPORT_C_INCLUDES := include
LOCAL_SRC_FILES := obj/local/$(TARGET_ARCH_ABI)/libFreeImage.a
include $(PREBUILT_STATIC_LIBRARY)
###############################################
which, taking note of a previous question I had about the NDK, should take care of specific architectures (I've build freeimage using all available architectures)
freeimage .a and .so libraries appear to build fine but on linking to my library when building the .so, I get this error:
[armeabi-v7a] SharedLibrary : libAnthracite.so
jni/freeimage/Source/LibWebP/./src/dsp/dsp.cpu.c:108: error: undefined reference to 'android_getCpuFamily'
jni/freeimage/Source/LibWebP/./src/dsp/dsp.cpu.c:109: error: undefined reference to 'android_getCpuFeatures'
jni/freeimage/Source/LibWebP/./src/dsp/dsp.dec.c:745: error: undefined reference to 'VP8DspInitNEON'
which is odd as both libraries do link cpufeatures, so it really ought to be there.
I'm declaring
APP_PLATFORM := android-14
APP_STL := gnustl_static
in the application.mk files for both projects.
Also, I've tried placing 'LOCAL_STATIC_LIBRARIES' in different positions in the files and linking libraries in different orders, although that's just guesswork.
Does anybody know what might be causing these linker errors?
Please follow the official guide to add cpu-features. TL;NR: add $(call import-module,android/cpufeatures) to your Android.mk.
I finally got it to work by ensuring that all of my 'application.mk' files for all four of the third party libraries I was using shared a common base file that looks like this:
APP_PLATFORM := android-15
APP_STL := c++_static
APP_ABI := all
APP_OPTIM := release
APP_SHORT_COMMANDS := true
Which makes keeping them in line easier, ensuring they're all built against the same libraries.
Also, I changed the STL implementation from 'gnustl_static' to 'c++_static'

How to resolve "Relocations in Generic ELF" during ndk-build?

I'm trying to build a static library using a standalone toolchain for a project that has its own build process, which I then wrap with a C++ library and expose to Android (compiled with ndk-build). However, on the ndk-build step I receive the following error:
➜ jni /Users/chrisfosterelli/Library/Android/sdk/ndk-bundle/ndk-build
[arm64-v8a] Compile++ : wrapper <= wrapper.cpp
In file included from /Users/chrisfosterelli/workspace/android/jni/wrapper.cpp:9:
In file included from ../prebuild/include/valhalla/meili/universal_cost.h:7:
In file included from ../prebuild/include/valhalla/sif/dynamiccost.h:4:
In file included from ../prebuild/include/valhalla/baldr/directededge.h:5:
../prebuild/include/valhalla/baldr/graphconstants.h:432:11: warning: 21 enumeration values not handled in switch: 'kRoad', 'kRamp', 'kTurnChannel'... [-Wswitch]
switch (use) {
^
1 warning generated.
[arm64-v8a] SharedLibrary : libwrapper.so
/Users/chrisfosterelli/Library/Android/sdk/ndk-bundle/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld: /Users/chrisfosterelli/workspace/android/jni/../prebuild/libvalhalla_meili.a(libvalhalla_meili_la-map_matcher_factory.o): Relocations in generic ELF (EM: 62)
[...above message repeated many times...]
/Users/chrisfosterelli/workspace/android/jni/../prebuild/libvalhalla_meili.a: error adding symbols: File in wrong format
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/chrisfosterelli/workspace/android/obj/local/arm64-v8a/libwrapper.so] Error 1
➜ jni ls /Users/chrisfosterelli/Library/Android/sdk/ndk-bundle/
This error indicates, as far as I can tell, that I'm trying to mix and match binaries compiled for different architectures. However, from what I can tell the library is the correct architecture:
root#eacbdb1c0e46:/meili/meili2/newtest# ar x libvalhalla_meili.a
root#eacbdb1c0e46:/meili/meili2/newtest# file libvalhalla_meili_la-map_matcher_factory.o
libvalhalla_meili_la-map_matcher_factory.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped
root#eacbdb1c0e46:/meili/meili2/newtest#
FWIW, these are my current Application.mk,
APP_STL := c++_static
APP_CPPFLAGS := -frtti -std=gnu++11 -D_GLIBCXX_USE_C99
APP_CPPFLAGS += -fexceptions
NDK_TOOLCHAIN_VERSION := clang
APP_LDFLAGS := -latomic
APP_PLATFORM := android-21
APP_ABI := arm64-v8a
and Android.mk,
LOCAL_PATH := $(call my-dir)
# static library info
include $(CLEAR_VARS)
LOCAL_MODULE := libvalhalla_meili
LOCAL_SRC_FILES := ../prebuild/libvalhalla_meili.a
LOCAL_EXPORT_C_INCLUDES := ../prebuild/include
include $(PREBUILT_STATIC_LIBRARY)
# wrapper info
include $(CLEAR_VARS)
LOCAL_C_INCLUDES += ../prebuild/include
LOCAL_MODULE := wrapper
LOCAL_SRC_FILES := wrapper.cpp
LOCAL_STATIC_LIBRARIES := libvalhalla_meili
include $(BUILD_SHARED_LIBRARY)
Any ideas how to resolve this? I've tried a number of things but all of them lead to more (more obscure) errors, so I'm hoping someone here can point me in the correct direction!
I discovered the problem, but I wish I had a more insightful answer. Apparently the build process had created two library files. The one that I inspected was, of course, ARM64. However the one that I actually copied to the Android device was x86.
So, the error message was correct and so was the library file, but there was more than one file involved. If you're running into the same problem and pretty sure your library is ARM64, double check that's actually the same file that is being compiled into the ndk build!

Android NDK returns an error "undefined reference to 'rand'"

I'm trying a webm decorder for Android x86 with libvpx.
I built the library by following command and got "libvpx.a".
../configure --target=x86-android-gcc --disable-vp8-encoder --disable-vp9-encoder --disable-examples --sdk-path=$ANDROID_NDK_ROOT --enable-pic --enable-postproc
When I use this library is by ndk-build on Windows, an error occurred.
C:/android/[project]/jni/../plib/libvpx.a(postproc_mmx.asm.o)(.text+0x1c8): error: undefined reference to 'rand'
C:/android/[project]/jni/../plib/libvpx.a(postproc_sse2.asm.o)(.text+0x65c): error: undefined reference to 'rand'
collect2.exe: error: ld returned 1 exit status
libvpx.a for armeabi didn't occur an error. Doesn't someone know solution?
(jni/Android.mk)
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := sublib
LOCAL_SRC_FILES := sublib.cpp
LOCAL_LDLIBS := -llog
LOCAL_STATIC_LIBRARIES := libvpx_pre
include $(BUILD_SHARED_LIBRARY)
include $(LOCAL_PATH)/../plib/Android_x86.mk
(plib/Android_x86.mk)
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libvpx_pre
LOCAL_SRC_FILES := libvpx.a
LOCAL_STATIC_LIBRARIES := cpufeatures
include $(PREBUILT_STATIC_LIBRARY)
$(call import-module,android/cpufeatures)
Contrary to the initial impression (from the subject), this isn't (directly) a duplicate of Cannot load library: reloc_library[1285]: cannot locate 'rand'.
It seems that when configuring libvpx with --target=x86-android-gcc, it actually doesn't automatically pick an android compiler or try to use android headers (contrary to what it does for armv7-android-gcc). (In fact, if you compile with --target=x86-android-gcc on OS X, it doesn't even build linux/android binaries, it will end up building a binary for OS X.)
Instead it builds pretty much as usual, using the normal system compiler, with the normal system headers (unless you manually specify them), which contain a normal rand function, which isn't available on Android. (On Android versions prior to 5.0, the rand function in stdlib.h is an inline function that actually maps to the lrand48 function, which is what the binary ends up linking to).
(Also, when building for android on arm, it doesn't seem to allow you to pick which android version you're targeting, so if your NDK contains android-21, it seems that it will try to build with that, which can also give you similar errors, such as in Cannot load library: reloc_library[1285]: cannot locate 'rand'.)
Since the configure script magic doesn't seem to set up the right things for building for x86 android (as it does for arm), you should be able to set it up yourself instead, which requires setting a bit more parameters:
export PATH=<NDK>/toolchains/x86-4.8/prebuilt/*x86*/bin:$PATH
ASFLAGS="-D__ANDROID__" CROSS=i686-linux-android- LDFLAGS="--sysroot=<NDK>/platforms/android-9/arch-x86" ./configure --target=x86-android-gcc --extra-cflags="--sysroot=<NDK>/platforms/android-9/arch-x86" --disable-examples
make
With this, I'm able to build a libvpx.a which should be built against the right headers, which hopefully should work fine for you.

fatal error: fitz.h: No such file or directory in muPDF library

I m trying to compile the muPDF lib in eclipse for android app since 3 days without any success
I downloaded and configured the android-ndk, cygwin
Im getting this still
15:25:36 **** Build of configuration Debug for project ChoosePDFActivity ****
"E:\\android-ndk\\android-ndk-r9d\\ndk-build.cmd" all
Android NDK: WARNING:E:/Workspace_SIL/ChoosePDFActivity//jni/Android.mk:mupdfcore: LOCAL_LDLIBS is always ignored for static libraries
Android NDK: WARNING:E:/Workspace_SIL/ChoosePDFActivity//jni/Android.mk:mupdfcore: LOCAL_LDLIBS is always ignored for static libraries
[armeabi] Compile thumb : mupdf <= mupdf.c
E:/Workspace_SIL/ChoosePDFActivity//jni/mupdf.c:10:18: fatal error: fitz.h: No such file or directory
compilation terminated.
make.exe: *** [E:/Workspace_SIL/ChoosePDFActivity//obj/local/armeabi/objs-debug/mupdf/mupdf.o] Error 1
15:25:36 Build Finished (took 489ms)
jni/mupdf.c:10:18: fatal error: fitz.h: No such file or directory
where I can get this God Damn fitz.h and other header files
see this happens in my eclipse
included the following paths for my header files
setup android Ndk path like this
Update1
Here is my Android.mk file
LOCAL_PATH := $(call my-dir)
TOP_LOCAL_PATH := $(LOCAL_PATH)
MUPDF_ROOT := ..
include $(TOP_LOCAL_PATH)/Core.mk
include $(TOP_LOCAL_PATH)/ThirdParty.mk
include $(CLEAR_VARS)
LOCAL_C_INCLUDES := \
$(MUPDF_ROOT)/draw \
$(MUPDF_ROOT)/fitz \
$(MUPDF_ROOT)/pdf
LOCAL_CFLAGS :=
LOCAL_MODULE := mupdf
LOCAL_SRC_FILES := mupdf.c
LOCAL_STATIC_LIBRARIES := mupdfcore mupdfthirdparty
LOCAL_LDLIBS := -lm -llog -ljnigraphics
include $(BUILD_SHARED_LIBRARY)
Check the jni folder and find the Anroid.mk. Open it and check whether you added the LOCAL_SRC_FILES and LOCAL_C_INCLUDES. The LOCAL_C_INCLUDES should be your .h files' path. The LOCAL_SRC_FILES should be every .c or .cpp file's path.
cygwin no t install properly, follow following links and sure your installations correctly than run some commands according to below links.
For window 7
For window XP
You're also using an old version of the MuPDF source code.
1) Use the latest version (1.5 currently, or better, work from git).
2) Don't build it using eclipse, use the supported ndk/sdk based build as described in platform/android/ReadMe.txt. If you want to use eclipse, do so only after you have managed to build it in the supported way.
3) Do not skip step 10 of the instructions. Seriously, why does everyone try to skip step 10?
4) If you get stuck, come talk to us in the #ghostscript irc channel on freenode. A weblink can be found to this on mupdf.com

Android bitmap.h is not found for native code compile

I am trying to compile code using the Android NDK. I have previously used this code fine, but changed one thing in it and now it will not compile. The error that shows up is:
"Compile++ thumb : filters <= filters.cpp
C:/Android/my-app//jni/filters.cpp:4:28: fatal error: android
/bitmap.h: No such file or directory
compilation terminated.
make: *** [C:/Android/my-app//obj/local/armeabi/objs/filters/
filters.o] Error 1
My bitmap.h file is defined in the library as:
#include <android/bitmap.h>
I know that bitmap.h is only there after a target-skd build of 8 or higher, and mine is a target of 10 and min of 8. Any suggestions? This is driving me crazy and used to work!Thanks for any help you can provide.
Edit: Here is my Android.mk file also
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := filters
LOCAL_SRC_FILES := filters.cpp
LOCAL_LDLIBS := -lm -llog -ljnigraphics
include $(BUILD_SHARED_LIBRARY)
Got it to work. I was using SDK tools revision 20, and platform-tools revision 12. In order to get it to compile, I had to specify the APP_PLATFORM in the command line (apparently these revisions default to something else).
Just ran:
ndk-build APP_PLATFORM=android-8
and it built!
Insert APP_PLATFORM=android-8 into file Application.mk
Well, the answer bellow helped me also.
I tried setting the APP_PLATFORM variabile to android-10 from Application.mk (as I expected this option should also be where the APP_ABI is), but that didn't help.
Pretty non-intuitive, but whatever works, right..?

Categories

Resources