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

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

libB.so（供应商提供的）是在AOSP构建时编译和链接的（供应商坚持以这种方式构建库，对此无能为力）。生成文件为libB.so将 STL 标志设置为 c++_shared，如下所示：

LOCAL_NDK_STL_VARIANT := c++_shared

当我查看 NEEDED 标签时libB.so库，我可以看到对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++ 的内容。所以我得到了这个

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]

我认为我不能（或应该）将两者捆绑在一起libc++.so and 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反而？也许有人有更好的建议来修复这种依赖性不匹配。

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

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

如果供应商提供的设备已将此库安装到系统映像（即 /system/lib64/libB.so，not包含在您的申请中），那么@alex-cohn 的答案中的指导适用。这就是 libandroid.so 等官方 NDK 库的构建方式。它们链接到系统的 libc++.so，但仅向应用程序公开 C ABI。只要供应商遵循这些准则，就可以了。

正如亚历克斯提到的，您引用的文件比实际情况稍微具有限制性。它is可以在同一个程序中使用多个 STL（否则 NDK 应用程序根本无法工作，因为平台和应用程序使用不同的 STL），但它确实需要非常仔细地管理 ABI 的表面积和大量的谨慎避免 ODR 违规。