android – AOSP的libc.是和NDK的libc _shared.so一样吗？

概述我正在一个 Android应用程序中工作,其中一个共享库(我在Android Studio中构建,我们称之为libA.so)由供应商动态加载另一个共享库提供程序(让我们称之为libB.so).我知道我不应该在我的应用程序中使用多个C运行时库( https://developer.android.com/ndk/guides/cpp-support.html#important_considerat 我正在一个 Android应用程序中工作,其中一个共享库(我在AndroID Studio中构建,我们称之为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.

总结

以上是内存溢出为你收集整理的android – AOSP的libc.是和NDK的libc _shared.so一样吗？全部内容，希望文章能够帮你解决android – AOSP的libc.是和NDK的libc _shared.so一样吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。