android - AOSP的libc++.so和NDK的libc++_shared.so一样吗？

Question

我正在开发一个 Android 应用程序，其中一个共享库(我在 Android Studio 中构建，我们称之为 libA.so)由供应商动态加载另一个共享库提供程序(让我们称它为 libB.so)。我知道我不应该在我的应用程序 (https://developer.android.com/ndk/guides/cpp-support.html#important_considerations) 中使用多个 C++ 运行时库，因此我们决定在两个库中使用 c++_shared。

libB.so(厂商提供的那个)在构建AOSP时编译链接(厂商非要这样构建库，没办法)。 libB.so 的 makefile 将 STL 标志设置为 c++_shared :

LOCAL_NDK_STL_VARIANT := c++_shared

当我查看 libB.so 库中的 NEEDED 标记时，我可以看到对 libc++.so 的依赖性

 0x0000000000000001 (NEEDED)             Shared library: [libdl.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc++.so] <----
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so]
 0x000000000000000e (SONAME)             Library soname: [libB.so]

当我运行 readelf -d libc++.so 检查 AOSP 的 libc++.so 的内容时，我得到了这个

Dynamic section at offset 0xe4b40 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000003 (PLTGOT)             0xe6310
 0x0000000000000002 (PLTRELSZ)           22128 (bytes)
 0x0000000000000017 (JMPREL)             0x39ff8
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000007 (RELA)               0x2ce58
 0x0000000000000008 (RELASZ)             53664 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffff9 (RELACOUNT)          380
 0x0000000000000006 (SYMTAB)             0x238
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000005 (STRTAB)             0xdeb8
 0x000000000000000a (STRSZ)              102917 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x270c0
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so]
 0x000000000000000e (SONAME)             Library soname: [libc++.so]
 0x000000000000001a (FINI_ARRAY)         0xe08e0
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000019 (INIT_ARRAY)         0xe5b38
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001e (FLAGS)              BIND_NOW
 0x000000006ffffffb (FLAGS_1)            Flags: NOW
 0x000000006ffffff0 (VERSYM)             0x2bb7c
 0x000000006ffffffc (VERDEF)             0x2cddc
 0x000000006ffffffd (VERDEFNUM)          1
 0x000000006ffffffe (VERNEED)            0x2cdf8
 0x000000006fffffff (VERNEEDNUM)         2
 0x0000000000000000 (NULL)               0x0

我知道 NDK 也提供了 libc++.so，但是当我在 Android NDK 分发的库中运行相同的命令时，我得到一个错误

readelf: Error: libc++.so: Failed to read file header

如果我没记错的话，那是因为在 NDK 中，libc++.so 实际上是一个链接描述文件。

libA.so(我用我的应用构建并加载 libB.so 的那个)最终依赖于 libc++_shared.so

Dynamic section at offset 0x4bca50 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so]
 0x0000000000000001 (NEEDED)             Shared library: [liblog.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc++_shared.so] <---
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
 0x000000000000000e (SONAME)             Library soname: [libA.so]

我认为我不能(或不应该)在我的应用中 bundle libc++.so 和 libc++_shared.so。

那么，AOSP的libc++.so和NDK的libc++_shared.so是一样的吗？

有人知道为什么 AOSP 添加动态依赖到 libc++.so 而不是 libc++_shared.so 即使 LOCAL_NDK_STL_VARIANT := c++_shared被使用？我应该要求我的提供者链接到 libc++_shared.so 吗？也许有人有更好的建议来解决这个依赖不匹配问题。

Answer 1

不，它们不等价。 AOSP 中的 libc++.so 是针对最新的(从技术上讲是 future API 级别)API 级别构建的，没有 libandroid_support。它是用一组不同的标志构建的，并且可能是一个不同的 ABI。它使用一组架构标志构建，允许编译器使用并非在所有 Android 设备上都可用的指令。它也是与NDK中的不同的修订，但对于不同的NDK版本也是如此，并且在决定它们是否兼容时意义不大。

如果供应商向您提供 libB.so 以将其包含在您的应用程序中，则他们构建它的方式不正确。正如您所注意到的，它链接到平台 libc++.so，应用程序无法访问该平台。你这边没有解决办法；供应商需要提供合适的 NDK 库。如果他们想继续使用 AOSP 构建系统，则需要设置 LOCAL_SDK_VERSION，这样 LOCAL_NDK_STL_VARIANT 就不会被忽略。

如果供应商提供的设备已将此库安装到系统镜像(即/system/lib64/libB.so，未包含在您的应用程序中)，则@alex-中的指南科恩的回答适用。这就是 libandroid.so 等官方 NDK 库的构建方式。它们链接到系统的 libc++.so，但只向应用程序公开 C ABI。只要供应商遵循这些准则，就可以了。

正如 Alex 所提到的，您引用的文件比实际情况略有限制。 是可以在同一个程序中使用多个 STL(否则 NDK 应用程序根本无法工作，因为平台和应用程序使用不同的 STL)，但这确实需要非常小心地管理表面您的 ABI 领域，并且要格外小心以避免违反 ODR。