分类导航

Android 发布时间：2022-04-28 发布网站：大佬教程 code.js-code.com

大佬教程收集整理的这篇文章主要介绍了android – AOSP的libc.是和NDK的libc _shared.so一样吗？，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。

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

构建AOSP时,libB.so(由供应商提供的)编译和链接(供应商坚持以这种方式构建库,对此无能为力). 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的内容时,我得到了这个

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和libc _shared.so.

那么,AOSP的libc.是否与NDK的libc _shared.so相同？

有人知道为什么即使使用了LOCAL_NDK_STL_VARIANT：= c _shared,AOSP也会为libc .so而不是libc _shared.so 添加动态依赖？我应该要求我的提供商链接libc _shared.so吗？也许有人有更好的建议来解决这种依赖性不匹配问题.

解决方法

不,他们不等同. AOSP中的libc .so是针对最新的(技术上是未来的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-cohn的答案中的指导适用.这就是建立像libandroid.so这样的官方NDK库的方式.它们链接到系统的libc .so,但只向应用程序公开C ABI.只要供应商遵循这些准则,这很好.

正如亚历克斯所提到的那样,你所引用的文件比现实情况稍微有些限制.可以在同一程序中使用多个STL(否则nDK应用程序根本不起作用,因为平台和应用程序使用不同的STL),但它确实需要非常仔细地管理您的ABI的表面区域和良好的谨慎行事,以避免违反ODR.