我正在考虑直接在我的文件系统中用uClibc库替换glibc库(libc.so)。它会起作用吗?或者我是否需要重新编译所有二进制文件?
答案 0 :(得分:1)
非常糟糕的主意。 uclibc的“About”页面上的第3句:
将应用程序从glibc移植到uClibc通常只需要重新编译源代码
答案 1 :(得分:1)
正如所有其他答案已经说过:这不起作用。
uClibc和glibc甚至没有相同的动态库加载器(ld-linux.so)。共享可执行文件指定了哪个动态库加载器以及它们需要哪些共享库。您可以使用readelf -l /path/to/executable
(对于动态库加载器)和readelf -d
来获取共享库的信息。
与glibc相关联的程序将提供如下内容:
INTERP 0x000154 0x00008154 0x00008154 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.3]
0x00000001 (NEEDED) Shared library: [libc.so.6]
与uClibc链接的程序将提供如下内容:
INTERP 0x000114 0x00008114 0x00008114 0x00014 0x00014 R 0x1
[Requesting program interpreter: /lib/ld-uClibc.so.0]
0x00000001 (NEEDED) Shared library: [libc.so.1]
答案 2 :(得分:0)
不,无论你怎么做,这都行不通。
来自过程链接表和全局偏移表的重要重定位的所有符号序号将不再正确。任何解决被拦截的符号散列部分的尝试都会引起恐慌,并且你会留下破碎的字节。即使您要解决这个令人震惊的混乱局面,您也会拥有一个半复制或溢出的页面,其中包含来自多个动态库的指令,这些库的大小不再正确解析。
另一方面,静态链接的二进制文件不受此更改的影响。