我有一个用musl libc编译的共享库。
$ readelf -d ./libinterop_d.so
Dynamic section at offset 0x8ecb0 contains 22 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so]
0x000000000000000f (RPATH) Library rpath: [/usr/local/musl/lib]
0x000000000000000c (INIT) 0x46350
0x000000000000000d (FINI) 0x7664a
0x0000000000000019 (INIT_ARRAY) 0x28e700
0x000000000000001b (INIT_ARRAYSZ) 64 (bytes)
0x000000000000001a (FINI_ARRAY) 0x28e740
0x000000000000001c (FINI_ARRAYSZ) 16 (bytes)
0x0000000000000004 (HASH) 0x158
0x0000000000000005 (STRTAB) 0xc940
0x0000000000000006 (SYMTAB) 0x2bc0
0x000000000000000a (STRSZ) 203286 (bytes)
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000003 (PLTGOT) 0x28f000
0x0000000000000002 (PLTRELSZ) 28056 (bytes)
0x0000000000000014 (PLTREL) RELA
0x0000000000000017 (JMPREL) 0x3f5b8
0x0000000000000007 (RELA) 0x3e358
0x0000000000000008 (RELASZ) 4704 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffff9 (RELACOUNT) 46
0x0000000000000000 (NULL) 0x0它链接到musl的libc.so
$ ldd ./libinterop_d.so
linux-vdso.so.1 => (0x00007fff566c9000)
libc.so => /usr/local/musl/lib/libc.so (0x00007f111398c000)现在,我遇到了将这个共享对象加载到java应用程序中的问题。但是如果我恢复到GNU的libc.so的链接,它就能工作。
GNU和musl的libc.so是否都在同一个进程中?java应用程序依赖于GNU的libc.so,但我希望共享对象使用musl的libc.so。
也许有一种方法可以将musl的libc.so重命名为musl-libc.so
发布于 2015-05-10 17:23:56
GNU和musl的libc.so是否都在同一个进程中?
两者都有可能装载,是的。但是结果很快就会崩溃,所以这是一件无用的事情。
但我希望共享对象使用musl的libc.so
但是为什么呢?
在任何情况下,您都不会让musl和glibc合作,您的选择要么是对所有事物使用glibc,要么使用musl来处理所有的事情。
也许有一种方法可以将musl的libc.so重命名为musl-libc.so
它们已经有了不同的名称:libc.so和libc.so.6。图书馆的命名并不重要。事实上,它们都提供了相同(相互冲突的)符号,这才是最重要的。
发布于 2016-09-08 15:25:37
当然,这是可能的,但您需要编写自己的加载程序。这是一个重要的任务--尽管你可以从现有的'musl‘和'glibc’加载器中复制其中的大部分。
https://stackoverflow.com/questions/30151808
复制相似问题