Where does libgnustl_shared.so come from? Why its size is different after I build?

Question

I'm building libraries for Android using the NDK (r11b) for armeabi-v7a and I found different versions of libgnustl_shared.so and can't understand why.

• In the ndk folder (in android-ndk-r11b\\sources\\cxx-stl\\gnu-libstdc++\\4.9\\libs\\armeabi-v7a\\libgnustl_shared.so) its size is 5593ko .

• After I build my project (a bunch of libraries) using ndk-build.cmd, the library (in libs\\armeabi-v7a\\libgnustl_shared.so) file size is 694ko .

• After I build my project (a bunch of libraries) using QtCreator, the library (in android-build\\libs\\armeabi-v7a\\libgnustl_shared.so) file size is 846ko . Note that the library packaged in the apk (in android-build\\bin) has the same size. Note also that QtCreator build log report it picked up the file from (android-ndk-r11b/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_shared.so)

Main question: Why is the file after compilation smaller than the original one? Does the linker/compiler shrink the file at some point (removing unused symbols)?

Bonus question: I finally build my project with QtCreator (ending up with a libgnustl_shared.so of 846ko ) and give my so files (but libgnustl_shared.so) to someone else who will integrate it in his own application. After he deployed his application, his IDE (Android studio I believe) deploys it with a libgnustl_shared.so of 694ko , and my code starts crashing in STL operations. Could those crashes be due to a mismatch with libgnustl_shared.so used? How should we fix that? (as QtCreator does not let me build with static version of libgnustl_shared.so, which version should we use in the end for deployment?)

Note that my project is compiled with QtCreator but does not use Qt (I use Qt for testing my libraries from a GUI, but the libraries themselves does not use Qt at all)

Answer 1

Why is the file after compilation smaller than the original one? Does the linker/compiler shrink the file at some point (removing unused symbols)?

Yes, shared libraries are stripped after being installed to the library out directory. The libraries in the NDK are not pre-stripped because doing so would prevent users from debugging them.

Note also that for r11 and earlier there are two armeabi-v7a libraries. The one you've indicated, and another in the "thumb" subdirectory. Only the thumb one was actually used (which is why the non-thumb one was removed in r12).

Could those crashs be due to a mismatch with libgnustl_shared.so used?

If they're different versions of libgnustl_shared.so (not from the same NDK version), yes, absolutely. If they're both from r11 and are both armeabi-v7a (thumb or non-thumb) then they should be compatible. If either is using the armeabi-v7a-hard version of the library (removed in r12), then that's definitely an issue as well. armeabi-v7a mixed with armeabi is a little less certain, but could possibly be a problem.