Git Product home page Git Product logo

ndk's Introduction

Android Native Development Kit (NDK)

The NDK allows Android application developers to include native code in their Android application packages, compiled as JNI shared libraries.

For what we're working on, see the milestones.

For further into the future, see the NDK Roadmap.

The source for the NDK is maintained in AOSP. See https://android.googlesource.com/platform/ndk/+/master/README.md.

RFC

This section lists any in-progress features with open discussion bugs. We're still working on these and want to hear from you, so please read the thread and join the discussion if you have anything to add!

  • None right now :)

NDK documentation

Tutorial and API reference documentation is available on the Android Developer website:

C library ("bionic") and dynamic linker documentation

The documentation for Android's C library ("bionic") may be useful:

Understanding crashes/tombstones

The documentation for Android OS developers has:

Other resources

ndk's People

Contributors

danalbert avatar enh avatar enh-google avatar jmgao avatar qchong avatar rprichard avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ndk's Issues

NDK r11b contains duplicated file

It looks like at least one file is duplicated in the Linux NDK r11b zip file.

theis@ubuntu5:~/tmp2$ unzip -vl android-ndk-r11b-linux-x86_64.zip | grep --ignore-case xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-24/arch-arm/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-24/arch-arm/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-24/arch-x86/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-24/arch-x86/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-24/arch-mips/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-24/arch-mips/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-24/arch-x86_64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-24/arch-x86_64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-24/arch-mips64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-24/arch-mips64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-24/arch-arm64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-24/arch-arm64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-21/arch-arm/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-21/arch-arm/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-21/arch-x86/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-21/arch-x86/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-21/arch-mips/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-21/arch-mips/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-21/arch-x86_64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-21/arch-x86_64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-21/arch-mips64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-21/arch-mips64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-21/arch-arm64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-21/arch-arm64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-23/arch-arm/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-23/arch-arm/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-23/arch-x86/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-23/arch-x86/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-23/arch-mips/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-23/arch-mips/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-23/arch-x86_64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-23/arch-x86_64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-23/arch-mips64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-23/arch-mips64/usr/include/linux/netfilter/xt_DSCP.h
1548  Defl:X      575  63% 2016-03-15 13:25 8d4f8e17  android-ndk-r11b/platforms/android-23/arch-arm64/usr/include/linux/netfilter/xt_dscp.h
1422  Defl:X      559  61% 2016-03-15 13:25 bfd72029  android-ndk-r11b/platforms/android-23/arch-arm64/usr/include/linux/netfilter/xt_DSCP.h

Why is native code compiled with -fno-strict-aliasing?

I've noticed this being true for quite a long time (also in r10 and probably earlier).

Is there some problem with using -fstrict-aliasing when compiling native code? Are there any incompatibilities, undefined behaviour one should watch for when using this optimisation flag?

ndk-gdb.py script is not working on Windows

On Windows ndk-gdb.py script from android-ndk-r11b always fails with the following error message:
c:\wrk\android-ndk-r11b\prebuilt\windows\bin>python ndk-gdb.py --launch-list --adb c:\wrk\android-sdk\platform-tools\adb.exe
WARNING: Failed to find jdb on your path, defaulting to --nowait
Traceback (most recent call last):
File "ndk-gdb.py", line 704, in
main()
File "ndk-gdb.py", line 583, in main
args.props = device.get_props()
File "c:\wrk\android-ndk-r11b\python-packages/adb/device.py", line 459, in get
_props
raise RuntimeError('invalid getprop line: "{}"'.format(line))
RuntimeError: invalid getprop line: ""
ndk-gdb.cmd script located in root NDK directory fails with another error:
$ ./ndk-gdb.cmd
File "C:\wrk\android-ndk-r11b\prebuilt\windows\bin\ndk-gdb", line 2
NDK_BIN_DIR=$(dirname $0)
^
SyntaxError: invalid syntax

Clang3.8 cross-compile linker issues libc (undefined references)

I'm trying to cross-compile zlib-1.2.8 with clang3.8/android-ndk-20160105 snapshot on Debian Jessie.

Compiles properly but linking gives undefined reference errors.
'CC=arm-linux-androideabi-gcc' compiles (and links) properly. But that's probably not meant by "Everyone should be switching to Clang".

Any idea what's wrong here?

export NDK=/home/bob/Android/android-ndk-20160105
export TOOLCHAIN=/home/bob/Android/mytoolchain
export PATH=$TOOLCHAIN/bin:$PATH
export SYSROOT=$TOOLCHAIN/sysroot
export CFLAGS="-O3 -fPIC -ffast-math -march=armv7-a --target=thumbv7a-none-linux-androideabi -mthumb -mcpu=cortex-a15 -mfpu=neon-vfpv4 -mfloat-abi=softfp -v"
export CXXFLAGS="$CFLAGS -stdlib=libc++ -std=c++14"
export CPPFLAGS="-DANDROID -DNDEBUG"
export LDFLAGS="--fix-cortex-a8"

export CC=arm-linux-androideabi-clang
export CXX=arm-linux-androideabi-clang++
export AR=arm-linux-androideabi-ar
export AS=arm-linux-androideabi-as
export LD=arm-linux-androideabi-ld
export RANLIB=arm-linux-androideabi-ranlib
export NM=arm-linux-androideabi-nm
export STRIP=arm-linux-androideabi-strip
export CHOST=arm-linux-androideabi

$NDK/build/tools/make-standalone-toolchain.sh --verbose --platform=android-21 --install-dir=$TOOLCHAIN --arch=arm --toolchain=arm-linux-androideabi-4.9 --use-llvm --stl=libc++

./configure --static --prefix=/home/bob/zlibout
make

This is the tail of the output:

[...]
 "/home/bob/Android/mytoolchain/bin/clang38" -cc1 -triple thumbv7-none-linux-android -emit-obj -disable-free -disable-llvm-verifier -main-file-name gzwrite.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -menable-no-infs -menable-no-nans -menable-unsafe-fp-math -fno-signed-zeros -freciprocal-math -ffp-contract=fast -ffast-math -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu cortex-a15 -target-feature +soft-float-abi -target-feature -fp-only-sp -target-feature -d16 -target-feature +vfp4 -target-feature -fp-armv8 -target-feature +neon -target-feature -crypto -target-abi aapcs-linux -mfloat-abi soft -target-linker-version 2.24 -v -dwarf-column-info -coverage-file /home/bob/encfs/zlib-1.2.8/gzwrite.o -resource-dir /home/bob/Android/mytoolchain/bin/../lib64/clang/3.8.243773 -D _LARGEFILE64_SOURCE=1 -D ANDROID -D NDEBUG -isysroot /home/bob/Android/mytoolchain/bin/../sysroot -internal-isystem /home/bob/Android/mytoolchain/bin/../sysroot/usr/local/include -internal-isystem /home/bob/Android/mytoolchain/bin/../lib64/clang/3.8.243773/include -internal-externc-isystem /home/bob/Android/mytoolchain/bin/../sysroot/include -internal-externc-isystem /home/bob/Android/mytoolchain/bin/../sysroot/usr/include -O3 -fdebug-compilation-dir /home/bob/encfs/zlib-1.2.8 -ferror-limit 19 -fmessage-length 100 -femulated-tls -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o gzwrite.o -x c gzwrite.c
clang -cc1 version 3.8.243773 based upon LLVM 3.6.0svn default target x86_64-unknown-linux
ignoring nonexistent directory "/home/bob/Android/mytoolchain/bin/../sysroot/usr/local/include"
ignoring nonexistent directory "/home/bob/Android/mytoolchain/bin/../sysroot/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/bob/Android/mytoolchain/bin/../lib64/clang/3.8.243773/include
 /home/bob/Android/mytoolchain/bin/../sysroot/usr/include
End of search list.
arm-linux-androideabi-ar rc libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
arm-linux-androideabi-clang -O3 -fPIC -ffast-math -march=armv7-a --target=thumbv7a-none-linux-androideabi -mthumb -mcpu=cortex-a15 -mfpu=neon-vfpv4 -mfloat-abi=softfp -v  -D_LARGEFILE64_SOURCE=1 -o example example.o -L. libz.a
clang version 3.8.243773
Target: thumbv7a-none-linux-android
Thread model: posix
Found candidate GCC installation: /home/bob/Android/mytoolchain/bin/../lib/gcc/arm-linux-androideabi/4.9
Selected GCC installation: /home/bob/Android/mytoolchain/bin/../lib/gcc/arm-linux-androideabi/4.9
Candidate multilib: .;@m32
Selected multilib: .;@m32
 "/home/bob/Android/mytoolchain/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld" --sysroot=/home/bob/Android/mytoolchain/bin/../sysroot -X --build-id --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /system/bin/linker -o example /home/bob/Android/mytoolchain/bin/../sysroot/usr/lib/../lib/crtbegin_dynamic.o -L. -L/home/bob/Android/mytoolchain/bin/../lib/gcc/arm-linux-androideabi/4.9 -L/home/bob/Android/mytoolchain/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/lib/../lib -L/home/bob/Android/mytoolchain/bin/../sysroot/usr/lib/../lib -L/home/bob/Android/mytoolchain/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/lib -L/home/bob/Android/mytoolchain/bin/../sysroot/usr/lib example.o libz.a -lgcc -ldl -lc -lgcc -ldl /home/bob/Android/mytoolchain/bin/../sysroot/usr/lib/../lib/crtend_android.o
libz.a(deflate.o):deflate.c:function deflateReset: error: undefined reference to '__aeabi_memclr'
libz.a(deflate.o):deflate.c:function deflateSetDictionary: error: undefined reference to '__aeabi_memclr'
libz.a(deflate.o):deflate.c:function fill_window: error: undefined reference to '__aeabi_memcpy'
libz.a(deflate.o):deflate.c:function fill_window: error: undefined reference to '__aeabi_memcpy'
libz.a(deflate.o):deflate.c:function fill_window: error: undefined reference to '__aeabi_memclr'
libz.a(deflate.o):deflate.c:function fill_window: error: undefined reference to '__aeabi_memclr'
libz.a(deflate.o):deflate.c:function deflate: error: undefined reference to '__aeabi_memcpy'
libz.a(deflate.o):deflate.c:function deflate: error: undefined reference to '__aeabi_memcpy'
clang38: error: linker command failed with exit code 1 (use -v to see invocation)
Makefile:170: recipe for target 'example' failed
make: *** [example] Error 1

Unable to use Clang as part of Android Studio

With the previous NDK bundle from Android Studio, you could tell Gradle to use Clang toolchain to compile the JNI library as in:

 android.ndk {
        platformVersion = "18"  // Must be in-sync with minSdkVersion.apiLevel
        moduleName = "jni"
        toolchain "clang"
        toolchainVersion "3.6"
        ...
}

With the new NDK bundle 11.0.0, this doesn't work anymore, with or without toolchainVersion and even if using llvm instead of clang for toolchain.

Gradle sync failed: Cause: org.gradle.api.internal.ExtensibleDynamicObject Consult IDE log for more details (Help | Show Log)

armeabi libatomic.a uses ifuncs

When compiling our app with libc++ runtime and clang, as soon as first native method is called, we get a SIGSEGV with invalid stack trace (stack trace points to file and line number which can be reached only from completely different JNI method).

When using libc++ + GCC, app crashes when attempting to throw c++ exception.

GNU STL + clang and GNU STL + GCC combinations work correctly. We've tested on Samsung Galaxy Ace: armeabi ABI + Android 2.3 (API level 10).

asan_device_setup error bricks phone

Platform - OSX 10.11.2
Device - Samsung Galaxy S3, Rooted

  1. Modify asan_device_setup to work on OSX
  • TMPDIRBASE=$(mktemp -d -t template)
    • TMPDIRBASE=$(mktemp -d)
      2) Run ./asan_device_setup --use-su
>> Remounting /system rw
Remounting /dev/block/platform/msm_sdcc.1/by-name/system at /system
Target architecture: arm
>> Pre-L device detected. Setting up app_process symlink.
>> Copying files from the device
>> New installation
>> Generating wrappers
Only in new/: app_process.wrap
Only in new/: asanwrapper
Only in new/: libclang_rt.asan-arm-android.so
>> Pushing files to the device
Installing /system/lib/libclang_rt.asan-arm-android.so 644 
4574 KB/s (691152 bytes in 0.147s)
/system/bin/sh: can't create "/system/lib/libclang_rt.asan-arm-android.so/libclang_rt.asan-arm-android.so": No such file or directory
Unable to open /system/lib/libclang_rt.asan-arm-android.so: No such file or directory
Unable to open /system/lib/libclang_rt.asan-arm-android.so: No such file or directory
Installing /system/bin/app_process.wrap 755 u:object_r:system_file:s0
16 KB/s (279 bytes in 0.016s)
/system/bin/sh: can't create "/system/bin/app_process.wrap/app_process.wrap": No such file or directory
Unable to open /system/bin/app_process.wrap: No such file or directory
Unable to open /system/bin/app_process.wrap: No such file or directory
chcon:  Could not label /system/bin/app_process.wrap with u:object_r:system_file:s0:  No such file or directory
Installing /system/bin/asanwrapper 755 u:object_r:system_file:s0
3 KB/s (71 bytes in 0.020s)
/system/bin/sh: can't create "/system/bin/asanwrapper/asanwrapper": No such file or directory
Unable to open /system/bin/asanwrapper: No such file or directory
Unable to open /system/bin/asanwrapper: No such file or directory
chcon:  Could not label /system/bin/asanwrapper with u:object_r:system_file:s0:  No such file or directory
>> Restarting shell (asynchronous)
>> Please wait until the device restarts

The device no longer boots. I imagine it's because of the errors in the system/lib paths. The file name is repeated mistakenly.

clang __thread caused linker error

ndk r11
APP_STL := c++_static
NDK_TOOLCHAIN_VERSION := clang

Trying to build shared library from single line file:
x.cpp:
__thread const char *x = "";
Got:

/Users/arseny30/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld: warning: shared library text segment is not shareable
/Users/arseny30/ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/darwin-x86_64/lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld: error: treating warnings as errors
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

Everything is OK, when I replace the line with:
__thread const char *x = nullptr;

ndk-stack does not work with 64-bit binaries

This was also issue in r10.

When using 64-bit ARM target on 64-bit device (e.g. Samsung Galaxy S6) and triggering segfault, while attempting to catch stack trace with adb logcat | ndk-stack -sym ./obj/local/arm64-v8a/, I get "File format not recognized" error:

$ adb logcat | ndk-stack -sym ./obj/local/arm64-v8a/
********** Crash dump: **********
Build fingerprint: 'samsung/zerofltexx/zeroflte:6.0.1/MMB29K/G920FXXU3DPB8:user/release-keys'
pid: 10952, tid: 11448, name: Recognition  >>> com.microblink.test <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x18
Stack frame #00 pc 00000000000752cc  /data/app/com.microblink.test-1/lib/arm64/libBlinkRecognizer.so (Java_com_microblink_recognition_NativeRecognizerWrapper_initNativeRecognizers+144): Routine ndk-stack: ./obj/local/arm64-v8a//libBlinkRecognizer.so: File format not recognized

When forcing the same crash on arm7 target on same device, I get much more information (note the source file and line numbers):

$ adb logcat | ndk-stack -sym ./obj/local/armeabi-v7a/
********** Crash dump: **********
Build fingerprint: 'samsung/zerofltexx/zeroflte:6.0.1/MMB29K/G920FXXU3DPB8:user/release-keys'
pid: 12211, tid: 12459, name: Recognition  >>> com.microblink.test <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
Stack frame #00 pc 000371cc  /data/app/com.microblink.test-2/lib/arm/libBlinkRecognizer.so (Java_com_microblink_recognition_NativeRecognizerWrapper_initNativeRecognizers+91): Routine Ref<protection::LicenseToken>::operator==(protection::LicenseToken const*) at /Users/dodo/Work/Microblink/android-core/core/CoreUtils/Source/Counted.hpp:191
Stack frame #01 pc 006f9e19  /data/app/com.microblink.test-2/oat/arm/base.odex (offset 0x4f1000) (long com.microblink.recognition.NativeRecognizerWrapper.initNativeRecognizers(long, long[], boolean, long)+140)
Stack frame #02 pc 006f9fbd  /data/app/com.microblink.test-2/oat/arm/base.odex (offset 0x4f1000) (long com.microblink.recognition.NativeRecognizerWrapper.llIIlIlIIl(long, long[], boolean, long)+88)
Stack frame #03 pc 006f7981  /data/app/com.microblink.test-2/oat/arm/base.odex (offset 0x4f1000) (void com.microblink.recognition.NativeRecognizerWrapper$1.run()+1636)
Stack frame #04 pc 0373da47  /system/framework/arm/boot.oat (offset 0x2f1e000)

I would be nice if ndk-stack could work with 64-bit binaries, since in development I only build native code to match ABI target of connected device (i.e. when I plug in SGS6, my gradle script builds native code only for AMR64, thus not wasting time on building native code for all supported platforms).

clang doesn't export explicit specializations function templates

Here:

Same code just works with gcc.

Compile command line:
/home/bogdan/necessitas/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -c -target armv7-none-linux-androideabi -march=armv7-a -mfpu=vfp -mfloat-abi=softfp -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -DANDROID -Wa,--noexecstack -fno-builtin-memmove --sysroot=/home/bogdan/necessitas/android-ndk/platforms/android-16/arch-arm/ -g -Os -fomit-frame-pointer -fno-strict-aliasing -mthumb -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -Wdate-time -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE -DQT_HAVE_POLL -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_DEBUG -I. -I/home/bogdan/work/qt/openssl-1.0.2f/include -Iglobal -I../3rdparty/pcre -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty/double-conversion/include -I../3rdparty/double-conversion/include/double-conversion -I../3rdparty/forkfd -I../../include -I../../include/QtCore -I../../include/QtCore/5.7.0 -I../../include/QtCore/5.7.0/QtCore -I.moc -isystem /home/bogdan/necessitas/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /home/bogdan/necessitas/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem /home/bogdan/necessitas/android-ndk/platforms/android-16/arch-arm/usr/include -I../../mkspecs/android-clang -o .obj/qjni.o kernel/qjni.cpp

Using precompiled header causes compilation error of tagged files

Problem is that precompiled header is built only for non-tagged source files and all files attempt to use it. So when a specific file is tagged with arm or neon tag, then this file cannot use PCH and compile warning is issued. When all warnings are treated as errors, this causes compilation failure.

This problem was also present in r10e.

Clang produces much larger binaries than GCC

Since now GCC is deprecated and Clang is new default, we would like to see Clang building binaries that are of similar size (when using same optimisation parameters).

Currently, binaries produced by Clang are up to 15% larger than binaries produced by GCC.

Here are sizes of our barcode library when compiled with GCC 4.9 and when compiled with default Clang in r11 (both use gnustl_static as c++ library):

$ ls -lh libs_clang/*
libs_clang/arm64-v8a:
total 6616
-rwxr-xr-x  1 dodo  staff   3.2M Mar 15 14:12 libBlinkBarcode.so

libs_clang/armeabi-v7a:
total 4904
-rwxr-xr-x  1 dodo  staff   2.4M Mar 15 14:12 libBlinkBarcode.so
[dodo@mujcek: androidJni (feature/ndk-r11)]$ ls -lh libs_gcc/*
libs_gcc/arm64-v8a:
total 6096
-rwxr-xr-x  1 dodo  staff   3.0M Mar 15 14:07 libBlinkBarcode.so

libs_gcc/armeabi-v7a:
total 4304
-rwxr-xr-x  1 dodo  staff   2.1M Mar 15 14:07 libBlinkBarcode.so

Can this be looked into in r11b or in r12?

Compile options used for Clang (armeabi-v7a target):

 -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -no-canonical-prefixes -fno-integrated-as -target armv7-none-linux-androideabi -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fno-exceptions -fno-rtti -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -mfpu=neon -Wno-parentheses-equality -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -Qunused-arguments -Wno-unknown-warning-option -Wno-psabi -Wno-unknown-pragmas -Werror -Wno-error=deprecated-declarations -Wno-error=cpp -Wall -Os -Wconversion -Wno-sign-conversion -Wno-write-strings -Wno-pragmas -Wvla -Wformat-security -Wextra -Wno-unused-parameter -Wno-ignored-qualifiers -Wno-type-limits -fvisibility=hidden -ffunction-sections -fstack-protector-all -Wa,--noexecstack -Wformat -Werror=format-security  -std=c++11 -Wno-overloaded-virtual -fvisibility-inlines-hidden  -fexceptions

and GCC (armeabi-v7a target - some warning flags are different or missing because those are not supported under GCC):

-fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -fno-exceptions -fno-rtti -mthumb -Os -g -DNDEBUG -fomit-frame-pointer -fno-strict-aliasing -finline-limit=64 -mfpu=neon -Wno-psabi -Wno-unknown-pragmas -Werror -Wno-error=deprecated-declarations -Wno-error=cpp -Wall -Os -Wconversion -Wno-sign-conversion -Wno-write-strings -Wno-pragmas -Wvla -Wformat-security -Wextra -Wno-unused-parameter -Wno-ignored-qualifiers -Wno-type-limits -fvisibility=hidden -ffunction-sections -fstack-protector-all -Wa,--noexecstack -Wformat -Werror=format-security  -std=c++11 -Wno-overloaded-virtual -fvisibility-inlines-hidden  -fexceptions

Generally, you can see that both Clang and GCC use -Os optimisation flag.

If achieving the same binary size as with GCC is not possible, we would like at least then better performance of binary produced by Clang. We need to somehow explain to our clients why our library will be 15% larger when we start using Clang.

undefined references

library compiled and ran fine with r10e. Now with r11b, my project fails to compile:

     [exec] libevent/evutil.c:2345: error: undefined reference to 'issetugid'
     [exec] libevent/evutil_rand.c:198: error: undefined reference to 'arc4random_addrandom'
     [exec] randutil.c:307: error: undefined reference to 'arc4random_stir'

However:

grep -r issetugid /usr/local/Cellar/android-ndk/r11b/platforms/android-14/arch-arm
/usr/local/Cellar/android-ndk/r11b/platforms/android-14/arch-arm/usr/include/unistd.h:extern int issetugid(void);
Binary file /usr/local/Cellar/android-ndk/r11b/platforms/android-14/arch-arm/usr/lib/libc.a matches

Etc.

Missing 64 bit FILE stream functions

The NDK doesn't have fopen64, fseeko64, ftello64, fgetpos64, fsetpos64 functions so needed to manipulate files larger than 4Gb (though it provides truncate64, lseek64, etc.).

Invalid toolchain path for Windows x86

The function of 'host-toolchain-path' defined in 'init.mk' uses $(HOST_TAG64) variable.
And this value represents as "windows-x86" on Windows 32 bit OS.
The problem is that all the toolchain doesn't have 'windows-x86' directory in android-ndk-r11b-windows-x86.zip package. It has only 'windows' directory.
So, it make a compile failure.

When I changed the directory name from "\toolchains\aarch64-linux-android-4.9\prebuilt\windows" to " "\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86", then the building was successful.

Why did you deprecate GCC?

Is it something wrong with GCC 5.x or upcoming 6 on Android that made you to take this decision?
I think is not a good idea to ditch gcc as long as clang still have some issues e.g. #9, #21.
IMHO having both will not hurt anyone.

ld.bfd 2.25.51 packaged with NDK r11 produces unsupported R_ARM_COPY relocation

I've been using ld.bfd 2.24.90 from NDK r10e without this issue, but after updating to r11 the new binutils consistently uses the R_ARM_COPY relocation for __sF. I'm building the object file that refers to __sF from D, using the llvm-based ldc compiler. However, the exact same object file is linked without R_ARM_COPY by both the older ld.bfd 2.24.90 or a newer 2.26.20160125 that I have locally installed, so this is probably a regression in ld.bfd 2.25.51. I don't have this issue with ld.gold in NDK r11, but I'm stuck with ld.bfd because I need a certain ELF section ordering.

For reference, here are the relocations in the stdio.o object file that refers to __sF:

Relocation section '.rel.data.stdin' at offset 0x800 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000000  00004602 R_ARM_ABS32       00000000   __sF
Relocation section '.rel.data.stdout' at offset 0x808 contains 1 entries:
Offset     Info    Type            Sym.Value  Sym. Name
00000000  00004602 R_ARM_ABS32       00000000   __sF
Relocation section '.rel.data.stderr' at offset 0x810 contains 1 entries:
Offset     Info    Type            Sym.Value  Sym. Name
00000000  00004602 R_ARM_ABS32       00000000   __sF

This produces the following relocation in the final command-line executable:

0178a1c0  0000b214 R_ARM_COPY        0178a1c0   __sF

Running that executable fails with an error about R_ARM_COPY not being supported. I'm unsure how to reproduce this using a C/C++ sample, but I'm guessing it might be a problem there too? I don't know enough about ELF relocations to say.

NDK r11 for Linux size / hash mismatch

The NDK download page currently reports the file size and SHA1 hash for Linux 64-bit (x86) android-ndk-r11-linux-x86_64.zip as 794012672 and 7b4e0d13f6bbf48dd87475be9d052273dc766fb6, respectively.

When I download the file, it is 796414803 bytes instead, and hashes to 8583ff5c22af1603129a6ec35afd3d51163e3fc1. (Tried downloading on Mac OS X 10.11.3 with both Firefox 45.0 and GNU Wget 1.17.1, same result).

Can you confirm?

Unknown argument -mandroid

Openssl (1.0.2g) adds -mandroid to the compile flags. This flag is not recognized by clang (clang38: error: unknown argument: '-mandroid'). Since it's a known gcc flag, I expect other libraries would do the same.

https://gcc.gnu.org/onlinedocs/gcc/GNU_002fLinux-Options.html provides the details for what that flag does in gcc. I'm not sure if this belongs here or as a clang issue, but I wanted to bring up this potential compatibility problem.

No way of detecting the exact version of the NDK programmatically

There is no way of detecting the exact version of the NDK programmatically for r11b. You can parse the source.properties file for the Pkg.Revision, but this is set to 11 for all of the r11 releases so far.

In previous NDK versions, there was a single RELEASE.TXT file that contained the full version of the NDK (for example, "r10e (64-bit)").

Having a way of detecting which version is useful for me because I have a script that configures the toolchains automatically for my project. If there is a problem with a particular NDK version, I want to be able to abort and put up an error message right away.

Support for _POSIX_THREAD_SAFE_FUNCTIONS

Though some (or may be all?) posix thread-safe functions is available in Bionic, the toolchain always undefine _POSIX_THREAD_SAFE_FUNCTIONS. Because of this, software cannot rely, that thread-safe functions available and must use not-safe alternatives, which causes bugs.

Can you enable this define?

no renderscript headers/library in r11

Hi,

In ndk r11, i don't see renderscript folder inside <ndk_folder>platforms\android-XXX\arch-arm\usr\include. Same is tryue for renderscript native .so file. This is on windows but i am pretty sure, the files were present with ndk r10.

No support for debugging library projects

In r10, I could run ndk-gdb --package=my.app.package to debug native code inside android library from test app.

In r11, ndk-gdb bash script has been removed and ndk-gdb.py does not support that. Please add this feature back.

libc++_shared (both hard float abi variants) fail to load properly

I've checked both the r11 and r10d releases of the libc++ library, and i'm pretty sure both suffer from the same issue.

Essentially they fail to resolve the symbol __aeabi_d2lz (note: this is only true for hard float abi variants - including the thumb hard float variants).

I've been able to work around it on some versions of android by providing a little shim library that pulls in this define from libgcc.a before attempting to load libc++shared but unfortunately this little trick doesnt seem to work on older variants of android. I'm guessing my only option might be to try and recompile the libc++ library. Anyways, just wanted to bring this up as an issue.

this a super simple repro... just call LoadLibrary("c++_shared")... and you should see the issues...

Cannot find module with tag 'cpufeatures' in import path

I have a project that has been working from Android NDK r4.

The project used to import the cpufeatures module. As part of opening this issue, I discovered documentation has likely changed over time and nowadays tells users to import android/cpufeatures by appending $(call import-module,android/cpufeatures) to Android.mk.

Anyways, when transitioning to NDK r11 or r11b and when doing it the old (likely erroneous) way and calling $(call import-module,cpufeatures) while APP_ABI being set to armeabi-v7a, I'm getting the following error:

Android NDK: /path/to/Android.mk: Cannot find module with tag 'cpufeatures' in import path
Android NDK: Are you sure your NDK_MODULE_PATH variable is properly defined ?
Android NDK: The following directories were searched:
Android NDK:

However, everything goes fine when compiling with APP_ABI=armeabi-v7a-hard.

In my case, the resolution is to use $(call import-module,android/cpufeatures) instead of $(call import-module,cpufeatures). However, the observed difference between APP_ABI=armeabi-v7a and APP_ABI=armeabi-v7a-hard makes me believe there's something to look into ndk-build internals in order to figure out why behavior is different.

clang doesn't make the difference between UL & ULL sufixes

thread/qthread.h:108:36: error: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 18446744073709551615 to
4294967295 [-Werror,-Wconstant-conversion]
bool wait(unsigned long time = ULONG_MAX);
~ ^~~~~~~~~
/home/bogdan/necessitas/android-ndk/platforms/android-9/arch-arm/usr/include/sys/limits.h:72:20: note: expanded from macro 'ULONG_MAX'

define ULONG_MAX 0xffffffffffffffffUL

                    ^~~~~~~~~~~~~~~~~~~~

Full command line:
/home/bogdan/necessitas/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ -c -target armv7-none-linux-androideabi -march=armv7-a -mfpu=vfp -mfloat-abi=softfp -ffunction-sections -funwind-tables -fstack-protector -fno-short-enums -DANDROID -Wa,--noexecstack -fno-builtin-memmove -D__LP64__ --sysroot=/home/bogdan/necessitas/android-ndk/platforms/android-9/arch-arm/ -g -Os -fomit-frame-pointer -fno-strict-aliasing -mthumb -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -Wdate-time -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE -DQT_HAVE_POLL -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_DEBUG -Wall -Wextra -Werror -Woverloaded-virtual -Wshadow -Wundef -Wnon-virtual-dtor -Wpointer-arith -Wformat-security -Wno-long-long -Wno-variadic-macros -pedantic-errors -Wchar-subscripts -Wold-style-cast -I. -I/home/bogdan/work/qt/openssl-1.0.2f/include -Iglobal -I../3rdparty/pcre -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty/double-conversion/include -I../3rdparty/double-conversion/include/double-conversion -I../3rdparty/forkfd -I../../include -I../../include/QtCore -I../../include/QtCore/5.7.0 -I../../include/QtCore/5.7.0/QtCore -I.moc -isystem /home/bogdan/necessitas/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /home/bogdan/necessitas/android-ndk/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem /home/bogdan/necessitas/android-ndk/platforms/android-9/arch-arm/usr/include -I../../mkspecs/android-clang -DQT_NO_CAST_TO_ASCII=1 -DQT_NO_CAST_FROM_ASCII=1 -DQT_STRICT_ITERATORS -DQT_NO_URL_CAST_FROM_STRING=1 -DQT_NO_CAST_FROM_BYTEARRAY=1 -DQT_NO_KEYWORDS=1 -DQT_USE_QSTRINGBUILDER -DQT_USE_FAST_OPERATOR_PLUS -Dsignals=int -Dslots=int -Demit=public: -Dforeach=public: -Dforever=public: -xc++ thread/qthread.h -o .obj/header_qthread.o
thread/qthread.h:108:36: error: implicit conversion from 'unsigned long long' to 'unsigned long' changes value from 18446744073709551615 to
4294967295 [-Werror,-Wconstant-conversion]
bool wait(unsigned long time = ULONG_MAX);
~ ^~~~~~~~~
/home/bogdan/necessitas/android-ndk/platforms/android-9/arch-arm/usr/include/sys/limits.h:72:20: note: expanded from macro 'ULONG_MAX'

define ULONG_MAX 0xffffffffffffffffUL

                    ^~~~~~~~~~~~~~~~~~~~

1 error generated.

Clang toolchains are still named *-clang3.6

In build/core/toolchains , the clang toolchain dir names still end in '-clang3.6' . Either '3.6' should be removed from these names or it should be updated to '3.8' as that is the version of llvm in toolchains/ .

r11 clang: undefined reference to 'dladdr'

/usr/local/google/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-5996/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/libcxxabi/src/Unwind/AddressSpace.hpp:448: error: undefined reference to 'dladdr'

NDK_TOOLCHAIN_VERSION := clang
APP_PLATFORM := android-4
APP_STL := c++_static

Arm gdb missing

pakage: android-ndk-r11b-windows-x86_64
android-ndk-r11b\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-gdb.exe not found

ndk-gdb.py fails

Output:

Traceback (most recent call last):
  File "prebuilt/darwin-x86_64/bin/ndk-gdb.py", line 38, in <module>
    import gdbrunner
ImportError: No module named gdbrunner

The relevant code is:

NDK_PATH = os.path.normpath(os.path.join(os.path.dirname(__file__), '../..'))
sys.path.append(os.path.join(NDK_PATH, "python-packages"))
import gdbrunner

ndk-gdb.py is at prebuilt/darwin-x86_64/bin/ndk-gdb.py, so this adds $NDK_PATH/prebuilt/darwin-x86_64/bin/../../python-packages, i.e. $NDK_PATH/prebuilt/python-packages. The correct path seems to be $NDK_PATH/python-packages. If I change '../..' to '../../..', it gets further (but still fails).

ndk r11b libc.so files don't contain all the symbols that r10e libc.so files did

I've tried to compile Firefox for Android with r11 and r11b, and I've found missing symbols (relative to r10e) in the libc.so files provided with both of them:

  • arc4random_addrandom
  • getdtablesize
  • arc4random_stir
  • getdents

Possibly others; this is my incomplete list from poking around with readelf -sW. The above symbols are declared in header files, so it's a bit frustrating that they don't exist in libc.so. (They do seem to exist in the libc.a files, FWIW.)

arc4random_addrandom's non-existence prevents Firefox for Android from compiling with r11b; the linker complains about not being able to find the symbol.

I think this is similar to #23 (comment), but different enough that the issues can't be solved by recompiling. It's not clear to me whether #23 addresses the libc.so or the libc.a files, though.

x86_64 prebuilt libraries are not linking correctly

While building a x86_64 app, with following settings:

// Toolchain config
-DANDROID_TOOLCHAIN_NAME=x86_64-4.9 -DANDROID_ABI=x86_64

// CMake config
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -march=x86-64 -msse4.2 -mpopcnt -m64 -mtune=intel -fPIC")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -O3 -march=x86-64 -msse4.2 -mpopcnt -m64 -mtune=intel -std=c++0x -fPIC")

Following errors appear:

/opt/android/ndk/android-ndk-r11/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9/../../../../x86_64-linux-android/bin/ld: warning: skipping incompatible /opt/android/ndk/android-ndk-r11/platforms/android-21/arch-x86_64/usr/lib/libm.so while searching for m
/opt/android/ndk/android-ndk-r11/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9/../../../../x86_64-linux-android/bin/ld: warning: skipping incompatible /opt/android/ndk/android-ndk-r11/platforms/android-21/arch-x86_64/usr/lib/libc.so while searching for c
/opt/android/ndk/android-ndk-r11/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9/../../../../x86_64-linux-android/bin/ld: warning: skipping incompatible /opt/android/ndk/android-ndk-r11/platforms/android-21/arch-x86_64/usr/lib/libdl.so while searching for dl

If I create a symlink pointing to /opt/android/ndk/android-ndk-r11/platforms/android-21/arch-x86_64/usr/lib64, named /opt/android/ndk/android-ndk-r11/platforms/android-21/arch-x86_64/usr/lib (so, replacing the lib folder with the lib64 one), errors disappear and compile process works fine.

Is it just a toolchain config error, or am I missing something in the config?

r11 clang: undefined reference to 'isnan' '__isinf'

jni/include/boost/math/special_functions/fpclassify.hpp:538: error: undefined reference to 'isnan'
/opt/android-ndk/sources/cxx-stl/llvm-libc++/libcxx/include/cmath:393: error: undefined reference to '__isinf'
/usr/local/google/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-5996/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../../android/support/src/stdio/strtod.c:3111: error: undefined reference to '__fpclassifyd'
/usr/local/google/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-5996/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../../android/support/src/stdio/vfprintf.c:250: error: undefined reference to '__isfinite'

NDK_TOOLCHAIN_VERSION := clang
APP_PLATFORM := android-8
APP_STL := c++_static

r11: libc++_static.a contains symbols in libc.a (causes multiple definition error)

The libc++_static.a static library contains (at least) the following symbols which are defined in libc.a:

  • isxdigit
  • vfprintf
  • iswalpha
  • towlower
  • towupper
  • __hdtoa

This makes it impossible to create a statically linked executable that uses libc++. (I realize this is not officially supported, but we don't have this problem with the bundled libstdc++ library.)

Also, the static libc++ library depends on libdl, which is available only as a shared library.

Is there any chance we could see this fixed for the next release? Thanks in advance!


Here's a very simple project for testing:

Application.mk:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64
APP_PLATFORM := android-24
APP_STL := c++_static
APP_CPPFLAGS := -std=c++11
NDK_TOOLCHAIN_VERSION := clang3.6

Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_SRC_FILES := main.cpp
LOCAL_MODULE := test
LOCAL_LDFLAGS := -static
include $(BUILD_EXECUTABLE)

main.cpp:

#include <string>

#include <cstdio>
#include <cstdlib>

int main(int argc, char *argv[])
{
    std::string blah("Hello world!");
    std::printf("%s\n", blah.c_str());
    return EXIT_SUCCESS;
}

To compile:

ndk-build NDK_PROJECT_PATH=. NDK_APPLICATION_MK=Application.mk APP_BUILD_SCRIPT=Android.mk

make-standalone-toolchain.sh doesn't work with Cygwin

The variable SYSTEM gets computed from "$HOST_OS-$HOST_ARCH" as "cygwin-x86_64" or cygwin-x86" and no such dir exists in toolchains/arm-linux-androideabi-4.9/prebuilt/ (obviously, windows or windows-x86_64 will be present)

Earlier, this script supported the option "--system=", which could be set to select the host and this wasn't an issue. This option is now removed causing it to error out.

Any pointers on this ?

Dump native callstack programmatically in Android

Hello,

I am working on adding debuggability to my app when there is a crash. I want to detect callstack when there is unhandled exception in native code and dump it into the ADB logs. For that, I am using _Unwind_Backtrace API to capture current stack trace and abi::__cxa_demangle to de-mangle it.

With this approach:

  1. We are getting all invalid IP (Instruction pointer address) for ARM builds
  2. In some instances, we get partially correct stack for X86 build
  3. In some instances, we are getting full accurate stack for x86 build

Can you please help me out how can we get the correct callstack for ARM and all builds of X86? Is this is a known bug for clang? If yes, is there a workaround I can use?

The code snippet below highlights the technique I use to get stack trace and de-mangle it:

void DumpCallStack()
{
    const void* frames[MAX_DEPTH];

    StackCrawlState state;
    ….

    _Unwind_Backtrace(TraceStack, (void*)&state);
       ….
   DemangleAndLogStack(frames,countOfFrames);
}

void DemangleAndLogStack(const void** frames, size_t countOfFrames)
{
    for (int i = 0; i < (int) countOfFrames; i++)
    {
        void*       offs;
        char        namebuf[1024];
        const void* ip              = frames[i];
        const char* mangled_name    = LookupSymbol(ip, &offs, namebuf, sizeof(namebuf));

        int         status          = 0;
        char*       demangled       = 0;

        demangled = abi::__cxa_demangle(mangled_name, 0, 0, &status);

        if (status == 0 && demangled)
        {
            log (ANDROID_LOG_ERROR, "STACKTRACE", "Frame:[#%d] \tIP:[%p] \tFunction:[%s]", i, ip, demangled);
            free(demangled);
        }
        else 
        {
            log(ANDROID_LOG_ERROR, "STACKTRACE", "Frame:[#%d] \tIP:[%p] \tFunction:[%s]", i, ip, mangled_name);
        }
    }
}

OS Version: Android L (5.0.2)

Thanks,
Dipankar

NDK r11 undefined reference

Since NDK r11, bcopy is no longer defined in libc and triggers an error during linkage of libusrsctp for instance:
error: undefined reference to 'bcopy'

Application.mk:

APP_STL := c++_static
APP_OPTIM := release
APP_ABI := armeabi-v7a x86
APP_PLATFORM := android-14
NDK_TOOLCHAIN_VERSION := clang

Android.mk

LOCAL_CFLAGS            +=  -g
LOCAL_STATIC_LIBRARIES := libusrsctp
LOCAL_LDLIBS            := -lm -llog -landroid -lz
LOCAL_ARM_MODE          := arm
LOCAL_CPPFLAGS          += -std=c++11
include $(BUILD_SHARED_LIBRARY)
$(call import-module,android/cpufeatures)

Is this issue related to #1 ?

ndk-gdb fails on OS X

Output:

readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path
prebuilt/darwin-x86_64/bin/ndk-gdb: line 2: /ndk-gdb.py: No such file or directory

BSD readlink does not have a no-argument -f option. From the manpage:

     -f format
             Display information using the specified format.  See the FORMATS section for a description of valid formats.

r11b: ndk-which dosen't work

Windows x64

C:\android\android-ndk-r11b>ndk-which gcc
'ndk-which' is not recognized as an internal or external command,
operable program or batch file.

I tried rename "ndk-which" to "ndk-which.cmd"

C:\android\android-ndk-r11b>ndk-which.cmd gcc
'C:\android\android-ndk-r11b\\prebuilt\windows-x86_64\bin\ndk-which' is not recognized as an internal or external command,
operable program or batch file.

Linux / Mac

$ ndk-which gcc
make: /home/android/android-ndk-r11b/prebuilt/linux-x86_64/bin/build/core/build-local.mk: No such file or directory
make: *** No rule to make target `/home/android/android-ndk-r11b/prebuilt/linux-x86_64/bin/build/core/build-local.mk'.  Stop.
/usr/lib/ccache/gcc

Compile error when including <complex>

Error:

~/android-ndk-r11/sources/cxx-stl/gnu-libstdc++/4.9/include/complex:53:45: error: missing terminating ' character [-Werror]
 #error Cannot include both <complex> and C99's <complex.h>

This can be fixed by changing lines 52-54 of $NDK_DIR/sources/cxx-stl/gnu-libstdc++/4.9/include/complex

from

#ifdef _GLIBCXX_C99_COMPLEX_H
#error Cannot include both <complex> and C99's <complex.h>
#endif

into

#ifdef _GLIBCXX_C99_COMPLEX_H
#error Cannot include both <complex> and C99 <complex.h>
#endif

Issues with autoconf & libtool

EDIT: Getting closer to the root issue, which is pretty different than the original mentioned problem. Changing the original post.

Configure scripts created by autogen / autoconf seem to expose a toolchain bug with clang / libc++

The scripts send CXXFLAGS to the linker stage when checking if the c++ compiler works. The flag "-funwind-tables" causes the linker to fail with the following error

configure:16806: checking whether the C++ compiler works
configure:16822: arm-linux-androideabi-clang++ -o conftest  --sysroot=~/Toolchains/arm/sysroot -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fpic -ffunction-sections **-funwind-tables** -fstack-protector -fno-strict-aliasing -frtti -fexceptions -march=armv7-a  conftest.cpp  >&5
/Volumes/Android/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-57861/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/libcxxabi/src/cxa_handlers.cpp:112: error: undefined reference to '__atomic_exchange_4'
/Volumes/Android/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-57861/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/libcxxabi/src/cxa_default_handlers.cpp:106: error: undefined reference to '__atomic_exchange_4'
/Volumes/Android/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-57861/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/libcxxabi/src/cxa_default_handlers.cpp:117: error: undefined reference to '__atomic_exchange_4'

The error is suppressed if you add "-E" to your CXX/CPP command, but causes issues with the compiler being in 'compile only mode' when you're actually trying to link.

Even without that specific flag, I am not able to build any project that uses autoconf / libtool. The furthest I've gotten is the linker stage of the library, where I again run into atomic symbol problems.

/Volumes/Android/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-92934/build-libc++/ndk/sources/cxx-stl/llvm-libc++/libcxx/include/atomic:922: error: undefined reference to '__atomic_fetch_add_4'
/Volumes/Android/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-92934/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/libcxxabi/src/cxa_handlers.cpp:112: error: undefined reference to '__atomic_exchange_4'
/Volumes/Android/buildbot/out_dirs/aosp-ndk-r11-release/build/tmp/build-92934/build-libc++/ndk/sources/cxx-stl/llvm-libc++/../llvm-libc++abi/libcxxabi/src/cxa_default_handlers.cpp:106: error: undefined reference to '__atomic_exchange_4'

I've reproduced this problem with zeromq 4.1.4 and protobuf 2.6.1. As far as I know, neither of these libraries are expecting libatomic at all.

Compile error when using clang and precompiled headers

In my Application.mk I've set NDK_TOOLCHAIN_VERSION=clang and in Android.mk I've defined LOCAL_PCH to point header I wish to get precompiled.

With GCC (NDK_TOOLCHAIN_VERSION unset), project can be built successfully. With clang I get following errors:

clang++: error: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated

ndk r11b __cxxabi_config still missing

I saw in the release notes for r11b that there use to be a problem with __cxxabi_config.h being missing for libc++

I'm trying to build boost 1.60 with r11b and I'm still seeing this issue.

include/c++/4.9/cxxabi.h:21:10: fatal error: '__cxxabi_config.h' file not found

__cxxabi_config.h exists in include/llvm-libc++abi/include but not include/c++/4.9/ so this might just be an include directory problem, or user error. Any guidance?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.