Why STLs libraries shipped with NDK standalone toolchain have different name mangling than STLs shipped with prebuilt AOSP clang compilers?

[Mirza Avdic]

Hi,

I am building a big project with CMake (just easier to manage than writing Android.bp files manually) using NDK standalone toolchain. The project runs perfectly fine on Android Pie. 

However, some project parts I would like to build as libraries that would be used by some other AOSP native components. Tipically I do the external building with CMake and write a small Android.bp file that includes these libraries as prebuilt static/dynamic libraries.

Then I include them as static/dynamic library dependencies that I link against when building a new binary with Soong.

I can link binaries built with Soong with my external libraries as long as my library interface does not use any STL data types (e.g. std::string). As soon as I start using STL data types in my library interfaces, the linking process fails with ''undefined references" for STL types used.

I delve into the problematic a little bit and discovered that STL libc++ shipped with NDK standalone toolchain and the one used by the prebuilt AOSP clang compiler (used by Soong) have different name manglings, even if the library and compiler versions are the same. The difference is in the inline namespacing.

Example (c++filt): 

std::__1::basic_string

std::__ndk1::basic_string

My question is, why the NDK libc++ inline namespaces are named differently? This is very annoying since I have to restrict my API to non-STL types.

Is there any way to configure the AOSP build system to use the NDK standalone toolchain to build the entire project? 

[Dan Albert]

Short answer: No. The mangling is different to prevent NDK binaries and platform binaries from communicating STL types to each other because doing so is invalid.

Using the NDK to build platform code is not and will never be supported. The NDK's entire purpose is building apps. I give a list of reasons why you shouldn't do this here: https://github.com/android/ndk/issues/744#issuecomment-436037520

If you want to build code for the platform you need to build it in the platform.

The reason for the different online namespace is there is no guarantee that the two ABIs are compatible. They might be at the exact versions you're using, but some day we hope to be able to take some ABI changes that are available in libc++ because they improve performance and remove undefined behavior. There is not C++ ABI between apps (and the NDK is only for apps) and the system; all calls between those two layers must be a plain C style ABI.

--
You received this message because you are subscribed to the Google Groups "android-llvm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-llvm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-llvm/b26464bc-1b99-4d75-a931-4d5c0405df9f%40googlegroups.com.

[Mirza Avdic]

Thanks for the clarification !!!

At least I know now that what I was doing is not officially supported by Google.

To unsubscribe from this group and stop receiving emails from it, send an email to androi...@googlegroups.com.