DanAlbert
commented
6 years ago Checking libzip.so, and sure enough:
$ readelf -sW libzip.so | grep _Unwind | grep UND 166: 00000000 0 FUNC WEAK DEFAULT UND __gnu_Unwind_Find_exidx 840: 00000000 0 FUNC WEAK DEFAULT UND __gnu_Unwind_Find_exidx
This one is actually okay. The _Unwind* symbols are a problem, but __gnu_Unwind_Find_exidx actually comes from libc (the pedigree of the various unwind functions is complicated to say the least).
It looks like you've got all the unwind symbols properly hidden. Unless there are some other libraries in the dependency chain that aren't mentioned or libz.so is actually a library you ship in your APK rather than the system's, I think you've got that part right. If your build system is building your library correctly, the next guess is usually that one of your third-party dependencies is broken, but it looks like your dependencies are fine too.
-latomic -latomic -lunwind -lc++abi -landroid_support -lgcc -lc++_shared
This looks mostly right, but it's not quite correct for libc++_shared. I'm not 100% certain it'll make a difference, but could you try:
-landroid_support -lunwind -latomic -lgcc -lc++_shared
The NDK includes some linker scripts that can deal with this for you, btw. The same directory that has libc++_shared also has libc++.so.$API files that will link things properly for that API level. Rather than doing what you're doing, you should be able to just link that file (give the full path to the linker script as if it were a library rather than -lc++, since it has a version attached to the name). That should work too and save you the trouble of maintaining the implementation detail.
Another choice would be getting your build system to use a standalone toolchain. If you've got resources to maintain a custom build system that may not actually be a better choice, but it is an option.
rprichard
goutnet
Description
I am trying to build an application that relies on the NDK for several libs.
Our lib (that I will call
libmylib.so) depends onlibzip.sowhich in turns relies onlibz.soIn short,
libmylib.so->libzip.so->libz.soI am not using ndkbuild or CMake, but rather integrated the last NDK (ndk 17) directly in our build system (custom makefiles that we have total control over).
The problem I am encountering only happens on ARM32, (all works fine on the other archs,
x86,x86_64andaarch64).What happens is that exceptions are not working properly, catching an exception in the same function works, but not from a function to another, in other word:
In our build system, we use
libc++_shared, I build libzip with clang, and use libz on the device. (that mean, we shiplibzip.so, but notlibz.so, as we are using the one on the device).After digging several issues that seems similar: #289 #774 It seems I am running in the same issue with the unwinder being used from two different places:
My understanding is that the issue I have is due to these two unreferenced symbols:
Checking
libzip.so, and sure enough:full output:
as my readelf output shows, I do have a mix of gnu symbols with clang, but what bothers me is that the only C++ library is our lib, libzip is a pure C library, and should not embed any exception unwinder (unless I am wrong somewhere…).
I have tried all the solutions proposed in #289 #774 #379 but could not resolve those two symbols :/
the NDK sits in
/usr/local/toolchains/android-ndk-r17bHere is the link command for libzip (output of clang -v) :
Here is the link command of our library:
I have been fighting this one for the last week… all works on other platforms, but am32 is giving me a hard time …
Could somebody help me figure out what is my mistake here?
@DanAlbert could I ask you a quick insight since you have been answering very similar questions in the past?
Environment Details
NDK Version: r17b Minimum API: android-21 ABI: armeabi-v7a Actual API of the device: android-24 STL: libc++ (shared) Toolchain: clang