My Android mixed (Java/NDK) project was going along nicely. Then suddenly I got a report that the native library failed to load on Android 1.5.
On the emulator, it reproduced perfectly. There's an UnsatisfiedLinkError thrown on the System.loadLibrary() call. The message says "library can't be found", but it's right there. Earlier versions of the app worked on Android 1.5; but I didn't test every single build on it.
I don't remember introducing any new RTL calls recently. Moreover, I've dumped all my imported symbols with readelf -s mylib.so | grep UND and matched them against readelf -s output for libc.so and libstdc++.so, as pulled from the 1.5 emulator. All the symbols can be found in either of those libraries, with the exception of three:
__cxa_begin_cleanup
__cxa_type_match
__cxa_call_unexpected
But those are weak references. They shouldn't cause an error. And also, I couldn't find them in Android 4.2's libraries either. Where do they reside? Are they indeed to blame?
If those symbols are causing the error, I didn't insert the dependency on them - the NDK toolchain did. Probably rebuilding against an older version of NDK libraries would help; is there a way to specify the NDK platform version to use on per-CPU_ABI basis? I'm building for all four CPU_ABI; in android-ndk-r9d\platforms\android-3, only ARM can be found.
EDIT: rebuilding with
ifeq ($(TARGET_ARCH_ABI),armeabi)
TARGET_PLATFORM := android-3
endif
doesn't help. Neither does scratching all but ARM and adding
APP_PLATFORM := android-3
to Application.mk.
Related
When I ndk compile a project using r10b 64 bit builder it compiles good without any problem
I am able to run the project in Lollipop succesfully and app runs as it supposed to be
But when I run the project in JellyBean at runtime I get the following
error
could not load library "libopenvpn.so" needed by
"/data/data/de.blinkt.openvpn/cache/pievpn.armeabi-v7a"; caused by
soinfo_relocate(linker.cpp:987): cannot locate symbol "srandom"
referenced by "libopenvpn.so"...CANNOT LINK EXECUTABLE
so when I researched I found its due to using 64 builder and solution is to use 32 bit builder.
When I use 32 builder I get the following error during compilation itself.
Android NDK: NDK Application 'local' targets unknown ABI(s): arm64-v8a
x86_64 Android NDK: Please fix the APP_ABI definition in
./jni/Application.mk
/Users/ShajilShocker/Documents/Android/NDK/android-ndk-r10b/build/core/setup-app.mk:112:
*** Android NDK: Aborting . Stop.
so If I omit arm64-v8a and x86_64 then it'd possibly compile but it won't run on 64 bit devices it seems.
is it possible that I can compile the same project first using 32 bit (commenting 64 architectures) and compile using 64 bit(uncomment 64 architectures) and run on both.
Any help is highly appreciated !
Thanks !
64-bit ARM & X86 devices (not sure about MIPS) running Lollipop can execute 32 or 64-bit native code (ARMv7a/ARMv8 and X86/X64). Android allows you to bind native code libraries with multiple ABI's (CPU-specific code) into an APK. These are also called "FAT" binaries. For example, to build a FAT binary containing both ARMv7a and ARMv8 code, add the following line to your Application.mk file:
APP_ABI := arm64-v8a armeabi-v7a
Then, in your Android.mk file, you can add specific settings for each CPU type:
ifeq ($(TARGET_ARCH_ABI),armeabi-v7a)
<your custom ARM 32-bit build instructions here>
endif
ifeq ($(TARGET_ARCH_ABI),arm64-v8a)
<your custom ARM 64-bit build instructions here>
endif
When you run your fat binary containing both 32 and 64-bit code on a 32-bit system, it will load the 32-bit code and vice versa. There shouldn't be any need to conditionally compile in the code for each target device. That's the purpose of the fat binary - the system automatically loads the library appropriate for the target architecture.
You should use NDK Revision 10c at least to support 64-bit system, according to the official documentation, https://developer.android.com/about/versions/android-5.0-changes.html#64BitSupport .
I'm trying to launch a native Android app on Intel Atom Z2560, but it always crashes in the same place with SIGILL ILL_ILLOPN (illegal operand) signal.
The crash doesn't happen with -O0.
The compiler I'm using is GCC 4.8 from NDK r10. I tried to set -march to atom, but that doesn't change anything.
Anybody knows how can I configure my build scripts so there is no incompatible code generated?
This is a known bug in NDK r10, see http://b.android.com/73843 for details on it. To avoid the issue, either use an older NDK version, or add (something like) this to your Android.mk:
ifeq ($(TARGET_ARCH_ABI), x86)
LOCAL_CFLAGS += -m32 # NDK r10 x86 bug workaround - http://b.android.com/73843
endif
I think this problem started when upgrading to the Juno Eclipse. I believe the C/C++ build environment was probably upgraded as well at the same time. The NDK was not upgraded.
We have a large mass of C code that compiles under several platforms. We are using the crystax-ndk (r6) to compile our C++ code. To know when we are compiling for Android, we have defined the following in the Android.mk
LOCAL_CFLAGS := -DANDROID_NDK \
-DDISABLE_IMPORTGL \
...
Then in some files we will include different headers depending upon the platform
#ifdef ANDROID_NDK
...
Our code compiles just fine and seems to run fine. However, when opening certain files the C/C++ code analyzer will find many errors. This appears to be because the analyzer doesn't know about the ANDROID_NDK defined variable.
Any idea why the code analyzer is not using the same #defines as the compiler? The code is almost uneditable with all the bogus errors the analyzer is reporting.
I saw you're comment about the analyzer you were refering to.
Eclipse CDT (C/C++ Development Toolkit) does not support parsing Android.mk yet neither does the NDK plugin add that functionality at the time of writing this.
Possible (ugly/annoying) workaround: Set up a header file setting the defines you are missing and include that header file to all files.
Use LOCAL_CPPFLAGS for C++ files and LOCAL_CFLAGS for C files in your Android.mk
I have a really simple helloworld.cpp program
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
And I'm trying to compile it for android x86 with the cross-compiler from the toolchain:
/Users/me/android-ndk-r8/toolchains/x86-4.4.3/prebuilt/darwin-x86/bin/i686-android-linux-g++ helloworld.cpp -L "/Users/me/android-ndk-r8/sources/cxx-stl/stlport/libs/x86/" -lstlport_static
However, I get errors:
helloworld.cpp:2:20: error: iostream: No such file or directory
Any idea why?
Check the documentation.html file included with the NDK, under "Standalone Toolchain". It says that if you invoke the compiler in this way you won't be able to "use any C++ STL". However it is possible, as the documentation explains, if you first create a "customized" toolchain installation, using something like the following command:
$NDK/build/tools/make-standalone-toolchain.sh --platform=android-8 --install-dir=/tmp/my-android-toolchain --arch=x86
where $NDK is the path to your NDK directory. Note the --arch=x86 which means that the toolchain is prepared specifically for the x86 Android. This prepares what you need in one directory, including the STL headers and folders. You should then be able to use -lstdc++ to link against the STL (static version), i.e. something like:
/tmp/my-android-toolchain/bin/i686-android-linux-g++ helloworld.cpp -lstdc++
For a more complete explanation, please see the NDK documentation.
The NDK documentation is not entirely accurate, at least not currently. In fact, it states when using the prebuilt toolchain "You won't be able to use any C++ STL (either STLport or the GNU libstdc++) with it.", but this is out of date. I created a small hello world program using the include with the same error. It can be solved without creating your own toolchain though, which is nice if you don't want to have to add one more step to your configuration process and allows you to always use the latest SDK platform without creating a new toolchain every time.
The NDK ships with the source code for several versions of standard C++ libraries: GAbi++, STLport, and GNU STL. Each flavor comes with prebuilt shared and static libs as well. My example below will use stlport.
To use the stand-alone toolchain at its installed location, you can do something like this:
export CXX='$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-g++ --sysroot="$NDK_ROOT/platforms/android-19/arch-arm"'
This, for example, would set your CXX compiler to compile ARM on the OS X system using SDK platform level 19. This much you probably already knew. Also, you would want to export your CC, CPP, LD, AR, and RANLIB if you use it. I also personally create an envar for READELF.
To add support for C++ libs, you could do something like follows:
$CXX helloworld.cpp -I$NDK_ROOT/sources/cxx-stl/stlport/stlport -L$NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi -lstlport_shared
Note that this will link the libstlport_shared.so which will now be required at runtime, so you may need to add a relative path to the command above to support that, depending on your APK structure. If you want to just test this simple case, you can just run this on the emulator as follows:
adb push a.out /data
adb push $NDK_ROOT/sources/cxx-stl/stlport/libs/armeabi/libstlport_shared.so /data
adb shell
# su
# cd /data
# chmod 777 a.out
# ./a.out
To get rid of the headache of dealing with shared library paths, you can also statically link the C++ library in by changing "-lstlport_shared" to "-lstlport_static". There are some consequences of doing this, as explained in the NDK Dev Guide. The biggest issue is due to having the static library linked in multiple places, causing:
- memory allocated in one library, and freed in the other would leak or even corrupt the heap.
- exceptions raised in libfoo.so cannot be caught in libbar.so (and may simply crash the program).
- the buffering of std::cout not working properly
A useful tool is also included to see what dependencies your program has, the readelf tool.
To see what other shared libraries your program requires, you can run the following:
$NDK_ROOT/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-readelf -a a.out | grep NEEDED
Other cool standard tools:
addr2line - convert a stack trace address to a line of code
nm - Displays the symbol table
objdump - displays info on an object
i call one of the functions from gnustl after it runs fine from prebuilt aosp arm-linux-androideabi-gcc --std=c++11 and after crashing error i cant get a backtrace from logs or reason, my hope is turning to crossbuilt qemu-linux-user to run host compiled i686 binary on the arm, difficulty is interacting with crosshost libs aapt from adt always crashes on any other than platform specific libs, unless kernel module packaged update is possible...
I'm trying to build this port of libSDL for Android, using the new Android NDK r7 release:
https://github.com/pelya/commandergenius
I know I am doing some things to some degree "unsupported": I am using cygwin&windows despite that being mentioned in the README as no longer being supported. That being said, I can hack out shell scripts and solve my problems as necessary and have it compiling but not linking.
So anyways I have compiling working until the linking (sorry for large block, relevant part trimmed below):
/cygdrive/c/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-ar crs obj/local/armeabi/libflac.a ./obj/local/armeabi/objs-debug/flac/src/ogg_decoder_aspect.o ./obj/local/armeabi/objs-debug/flac/src/md5.o ./obj/local/armeabi/objs-debug/flac/src/stream_decoder.o ./obj/local/armeabi/objs-debug/flac/src/fixed.o ./obj/local/armeabi/objs-debug/flac/src/memory.o ./obj/local/armeabi/objs-debug/flac/src/stream_encoder.o ./obj/local/armeabi/objs-debug/flac/src/window.o ./obj/local/armeabi/objs-debug/flac/src/cpu.o ./obj/local/armeabi/objs-debug/flac/src/ogg_encoder_aspect.o ./obj/local/armeabi/objs-debug/flac/src/lpc.o ./obj/local/armeabi/objs-debug/flac/src/float.o ./obj/local/armeabi/objs-debug/flac/src/bitmath.o ./obj/local/armeabi/objs-debug/flac/src/metadata_object.o ./obj/local/armeabi/objs-debug/flac/src/ogg_helper.o ./obj/local/armeabi/objs-debug/flac/src/metadata_iterators.o ./obj/local/armeabi/objs-debug/flac/src/bitreader.o ./obj/local/armeabi/objs-debug/flac/src/bitwriter.o ./obj/local/armeabi/objs-debug/flac/src/stream_encoder_framing.o ./obj/local/armeabi/objs-debug/flac/src/crc.o ./obj/local/armeabi/objs-debug/flac/src/format.o ./obj/local/armeabi/objs-debug/flac/src/ogg_mapping.o
C:/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld.exe: cannot find -lgnustl_static
collect2: ld returned 1 exit status
/cygdrive/c/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/arm-linux-androideabi-ar crs obj/local/armeabi-v7a/libflac.a ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_decoder_aspect.o ./obj/local/armeabi-v7a/objs-debug/flac/src/md5.o ./obj/local/armeabi-v7a/objs-debug/flac/src/stream_decoder.o ./obj/local/armeabi-v7a/objs-debug/flac/src/fixed.o ./obj/local/armeabi-v7a/objs-debug/flac/src/memory.o ./obj/local/armeabi-v7a/objs-debug/flac/src/stream_encoder.o ./obj/local/armeabi-v7a/objs-debug/flac/src/window.o ./obj/local/armeabi-v7a/objs-debug/flac/src/cpu.o ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_encoder_aspect.o ./obj/local/armeabi-v7a/objs-debug/flac/src/lpc.o ./obj/local/armeabi-v7a/objs-debug/flac/src/float.o ./obj/local/armeabi-v7a/objs-debug/flac/src/bitmath.o ./obj/local/armeabi-v7a/objs-debug/flac/src/metadata_object.o ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_helper.o ./obj/local/armeabi-v7a/objs-debug/flac/src/metadata_iterators.o ./obj/local/armeabi-v7a/objs-debug/flac/src/bitreader.o ./obj/local/armeabi-v7a/objs-debug/flac/src/bitwriter.o ./obj/local/armeabi-v7a/objs-debug/flac/src/stream_encoder_framing.o ./obj/local/armeabi-v7a/objs-debug/flac/src/crc.o ./obj/local/armeabi-v7a/objs-debug/flac/src/format.o ./obj/local/armeabi-v7a/objs-debug/flac/src/ogg_mapping.o
C:/and/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld.exe: cannot find -lgnustl_static
collect2: ld returned 1 exit status
Relevant failure, if you can't parse that wall of text:
ld.exe: cannot find -lgnustl_static
Now, if I look at the Windows NDK release I find gnustl_* files here:
under ./android-ndk-r7/sources:
./cxx-stl/gnu-libstdc++/libs/armeabi/libgnustl_shared.so
./cxx-stl/gnu-libstdc++/libs/armeabi/libgnustl_static.a
./cxx-stl/gnu-libstdc++/libs/armeabi-v7a/libgnustl_shared.so
./cxx-stl/gnu-libstdc++/libs/armeabi-v7a/libgnustl_static.a
./cxx-stl/gnu-libstdc++/libs/x86/libgnustl_shared.so
./cxx-stl/gnu-libstdc++/libs/x86/libgnustl_static.a
I looked also at the linux android NDK distribution and they are packaged the same (only have libgnustl files, built, under the sources directory).
So I have 3 questions:
why would we be using -l to link libgnustl_static when it's a .a
file? Shouldn't that be just including the .a file in the object
list, or alternately be -lgnustl_shared?
why are these files only under "sources"? I would have expected them to be in the "toolchains" library NDK directory. How does anyone ever link against libgnustl?
Can I copy these files somewhere where they'll be seen by the linker? Just adding their directory with -L hasn't seemed to work, and plus I need to get the right versions linked with the right build target (armeabi vs armeabi-v7 vs x86)
This is a bug in gcc/NDK that manifests itself slightly different on Linux, Cygwin, and Windows (non Cygwin).
Here's what I did to fix it (works for Linux and for one of my developers who is blind and has to use Cygwin)...
Remove the line that says, APP_STL := gnustl_static from your Application.mk (it's broken in the NDK, and it's broken slightly differently on Linux Cygwin, Windows)
add a line to $(LOCAL_LDLIBS) in your Android.mk file that says:
$(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi-v7a/libgnustl_static.a
also add two lines to Android.mk that say:
LOCAL_C_INCLUDES := $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.6/include
LOCAL_C_INCLUDES += $(NDK_ROOT)/sources/cxx-stl/gnu-libstdc++/4.6/libs/armeabi-v7a/include
The foregoing will accomplish what having, APP_STL := gnustl_static in your Application.mk was supposed to.
In case this plagues anyone else, the solution is to remove -lgnustl_static and instead list
c:\path\to\armeabi\libs\libgnustl_static.a in the linker command.
Do not use /cygdrive style path, as the linker will fail to find the file. Use actual c:\...