单个主机上有多个glibc库
我的linux(SLES-8)服务器目前有glibc-2.2.5-235,但我有一个程序无法在这个版本上运行,需要glibc-2.3.3.
是否可以在同一主机上安装多个glibc？
这是我在旧glibc上运行程序时遇到的错误:
./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./myapp) ./myapp: /lib/i686/libpthread.so.0: version `GLIBC_2.3.2' not found (required by ./myapp) ./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./libxerces-c.so.27) ./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by ./libstdc++.so.6) ./myapp: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by ./libstdc++.so.6)
所以我创建了一个名为newglibc的新目录,并将以下文件复制到:
libpthread.so.0 libm.so.6 libc.so.6 ld-2.3.3.so ld-linux.so.2 -> ld-2.3.3.so
和
export LD_LIBRARY_PATH=newglibc:$LD_LIBRARY_PATH
但是我收到一个错误:
./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libpthread.so.0) ./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by libstdc++.so.6) ./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libm.so.6) ./myapp: /lib/ld-linux.so.2: version `GLIBC_2.3' not found (required by ./newglibc/libc.so.6) ./myapp: /lib/ld-linux.so.2: version `GLIBC_PRIVATE' not found (required by ./newglibc/libc.so.6)
所以它似乎仍然链接到/ lib而不是从我放置它们的位置拾取？
谢谢
很可能在同一系统上有多个版本的glibc(我们每天都这样做).
但是,您需要知道glibc包含许多必须匹配的部分(200多个共享库).其中一个是ld-linux.so.2,它必须与libc.so.6匹配,否则你会看到你看到的错误.
ld-linux.so.2的绝对路径在链接时硬编码到可执行文件中,并且在链接完成后无法轻松更改.
要构建一个可以使用新glibc的可执行文件,请执行以下操作:
g++ main.o -o myapp ... \ -Wl,--rpath=/path/to/newglibc \ -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2
在-rpath连接选项将在库运行时加载器搜索/path/to/newglibc(这样你就不必设置LD_LIBRARY_PATH运行前),而-dynamic-linker选择将"烤"路径纠正ld-linux.so.2到应用程序中.
如果您无法重新链接myapp应用程序(例如,因为它是第三方二进制文件),并非所有内容都丢失,但它会变得更加棘手.一种解决方案是为其设置适当的chroot环境.另一种可能性是使用rtldi和二进制编辑器.
这个问题很老,其他答案都很陈旧."受雇俄语"的回答非常好,信息丰富,但只有拥有源代码才有效.如果你不这样做,那么当时的替代方案就非常棘手.幸运的是,现在我们有一个简单的解决方案来解决这个问题(在他的一个回复中评论),使用patchelf.你所要做的就是:
$ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp
之后,您可以执行您的文件:
$ ./myapp
chroot谢天谢地,不需要或手动编辑二进制文件.但是,如果你不确定你在做什么,请记住在修补它之前备份你的二进制文件,因为它会修改你的二进制文件.对其进行修补后,无法将旧路径还原为interpreter/rpath.如果它不起作用,你必须继续修补它,直到找到实际工作的路径......好吧,它不一定是试错过程.例如,在OP的示例中,他需要GLIBC_2.3,因此您可以使用以下命令轻松找到哪个lib提供该版本strings:
$ strings /lib/i686/libc.so.6 | grep GLIBC_2.3 $ strings /path/to/newglib/libc.so.6 | grep GLIBC_2.3
从理论上讲,第一个grep会变空,因为系统libc没有他想要的版本,第二个grep应该输出GLIBC_2.3,因为它有版本myapp正在使用,所以我们知道我们可以patchelf使用该路径的二进制文件.
当您尝试在linux中运行二进制文件时,二进制文件会尝试加载链接器,然后加载库,它们应该都在路径和/或正确的位置.如果问题在于链接器,并且您想要找出二进制文件要查找的路径,可以使用以下命令找到:
$ readelf -l myapp | grep interpreter [Requesting program interpreter: /lib/ld-linux.so.2]
如果您的问题与libs有关,那么将为您提供libs的命令是:
$ readelf -d myapp | grep Shared $ ldd myapp
这将列出您的二进制文件所需的库,但您可能已经知道有问题的库,因为它们已经在OP的情况下产生错误.
"patchelf"适用于您在尝试运行程序时可能遇到的许多不同问题,这些问题与这两个问题有关.例如,如果你得到:ELF file OS ABI invalid,可以通过设置一个新的加载器(--set-interpreter命令的一部分)来修复它,正如我在这里解释的那样.另一个例子是用于获取的问题No such file or directory,当你运行一个文件,该文件是存在的,可执行的,作为例证这里.在这种特殊情况下,OP错过了加载程序的链接,但在您的情况下,您可能没有root访问权限且无法创建链接.设置新的解释器可以解决您的问题.
感谢雇用俄罗斯人和Michael Pankov的洞察力和解决方案!
使用LD_PRELOAD:将您的库放在man lib目录之外的某个位置并运行:
LD_PRELOAD='mylibc.so anotherlib.so' program
请参阅:维基百科文章
首先,每个动态链接程序最重要的依赖是链接器.所有库都必须与链接器的版本匹配.
让我们采取简单的措施:我有新的ubuntu系统,我运行一些程序(在我的例子中它是D编译器 - ldc2).我想在旧的CentOS上运行它,但由于旧的glibc库,它是不可能的.我有
ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2) ldc2-1.5.0-linux-x86_64/bin/ldc2: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ldc2-1.5.0-linux-x86_64/bin/ldc2)
我必须将所有依赖项从ubuntu复制到centos.正确的方法如下:
首先,让我们检查所有依赖项:
ldd ldc2-1.5.0-linux-x86_64/bin/ldc2
linux-vdso.so.1 => (0x00007ffebad3f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f965f597000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f965f378000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f965f15b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f965ef57000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f965ec01000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f965e9ea000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f965e60a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f965f79f000)
linux-vdso.so.1不是真正的库,我们不必关心它.
/lib64/ld-linux-x86-64.so.2是链接器,linux使用它将可执行文件与所有动态库链接起来.
其余的文件都是真正的库,所有这些文件和链接器一起必须复制到centos中的某个地方.
假设所有库和链接器都在"/ mylibs"目录中.
ld-linux-x86-64.so.2 - 正如我已经说过的 - 是链接器.它不是动态库,而是静态可执行文件.你可以运行它,看看它甚至有一些参数,例如--library-path(我会回到它).
在linux上,动态链接的程序可以仅通过其名称来启动,例如
/bin/ldc2
Linux将此类程序加载到RAM中,并检查为其设置的链接器.通常,在64位系统上,它是/lib64/ld-linux-x86-64.so.2(在您的文件系统中,它是实际可执行文件的符号链接).然后linux运行链接器并加载动态库.
您也可以稍微更改一下并执行此操作:
/mylibs/ld-linux-x86-64.so.2 /bin/ldc2
这是强制linux使用特定链接器的方法.
现在我们可以返回前面提到的参数--library-path
/mylibs/ld-linux-x86-64.so.2 --library-path /mylibs /bin/ldc2
它将运行ldc2并从/ mylibs加载动态库.
这是使用选择(非系统默认)库调用可执行文件的方法.
此设置可能有效并且快速，因为它不会重新编译整个GCC工具链，而只是glibc。
但是，因为它使用的主机C运行对象，是不可靠的crt1.o，crti.o以及crtn.o由glibc的提供。在以下网址中提到了这一点：https : //sourceware.org/glibc/wiki/Testing/Builds? action = recall & rev =21#Compile_against_glibc_in_an_installed_location这些对象会进行glibc所依赖的早期设置，所以如果事情崩溃了，我不会感到惊讶。以及非常巧妙的方式
有关更可靠的设置，请参阅下面的设置2。
构建glibc并在本地安装：
export glibc_install="$(pwd)/glibc/build/install" git clone git://sourceware.org/git/glibc.git cd glibc git checkout glibc-2.28 mkdir build cd build ../configure --prefix "$glibc_install" make -j `nproc` make install -j `nproc`
test_glibc.c
#define _GNU_SOURCE #include#include #include #include #include atomic_int acnt; int cnt; int f(void* thr_data) { for(int n = 0; n < 1000; ++n) { ++cnt; ++acnt; } return 0; } int main(int argc, char **argv) { /* Basic library version check. */ printf("gnu_get_libc_version() = %s\n", gnu_get_libc_version()); /* Exercise thrd_create from -pthread, * which is not present in glibc 2.27 in Ubuntu 18.04. * /sf/ask/17360801/#52453291 */ thrd_t thr[10]; for(int n = 0; n < 10; ++n) thrd_create(&thr[n], f, NULL); for(int n = 0; n < 10; ++n) thrd_join(thr[n], NULL); printf("The atomic counter is %u\n", acnt); printf("The non-atomic counter is %u\n", cnt); }
编译并运行test_glibc.sh：
#!/usr/bin/env bash
set -eux
gcc \
-L "${glibc_install}/lib" \
-I "${glibc_install}/include" \
-Wl,--rpath="${glibc_install}/lib" \
-Wl,--dynamic-linker="${glibc_install}/lib/ld-linux-x86-64.so.2" \
-std=c11 \
-o test_glibc.out \
-v \
test_glibc.c \
-pthread \
;
ldd ./test_glibc.out
./test_glibc.out
程序输出预期的结果：
gnu_get_libc_version() = 2.28 The atomic counter is 10000 The non-atomic counter is 8674
该命令改编自https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location，但--sysroot由于以下原因而失败：
cannot find /home/ciro/glibc/build/install/lib/libc.so.6 inside /home/ciro/glibc/build/install
所以我删除了
ldd输出确认ldd我们刚刚构建的和库实际上正在按预期使用：
+ ldd test_glibc.out
linux-vdso.so.1 (0x00007ffe4bfd3000)
libpthread.so.0 => /home/ciro/glibc/build/install/lib/libpthread.so.0 (0x00007fc12ed92000)
libc.so.6 => /home/ciro/glibc/build/install/lib/libc.so.6 (0x00007fc12e9dc000)
/home/ciro/glibc/build/install/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fc12f1b3000)
该gcc编译调试输出显示，使用我的主机运行时对象，如前面提到的，但我不知道如何解决它是坏的，例如，它包含：
COLLECT_GCC_OPTIONS=/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crt1.o
现在让我们用以下命令修改glibc：
diff --git a/nptl/thrd_create.c b/nptl/thrd_create.c
index 113ba0d93e..b00f088abb 100644
--- a/nptl/thrd_create.c
+++ b/nptl/thrd_create.c
@@ -16,11 +16,14 @@
License along with the GNU C Library; if not, see
+
#include "thrd_priv.h"
int
thrd_create (thrd_t *thr, thrd_start_t func, void *arg)
{
+ puts("hacked");
_Static_assert (sizeof (thr) == sizeof (pthread_t),
"sizeof (thr) != sizeof (pthread_t)");
然后重新编译并重新安装glibc，然后重新编译并重新运行我们的程序：
cd glibc/build make -j `nproc` make -j `nproc` install ./test_glibc.sh
并且我们看到hacked印刷次数比预期的要多。
这进一步证实了我们实际上使用了编译的glibc，而不是宿主的glibc。
在Ubuntu 18.04上测试。
这是设置1的替代形式，这是最正确的设置我已经取得了远：一切是正确的，因为据我可以观察到，包括C运行时的对象，如crt1.o，crti.o和crtn.o。
在此设置中，我们将编译一个完整的专用GCC工具链，该工具链使用所需的glibc。
这种方法的唯一缺点是构建将花费更长的时间。但是我不会冒任何减少的生产设置风险。
crosstool-NG是一组脚本，可以为我们下载并编译所有内容，包括GCC，glibc和binutils。
是的，GCC构建系统太糟糕了，为此我们需要一个单独的项目。
这种设置并不完美，因为crosstool-NG不支持在没有额外-Wl标志的情况下构建可执行文件，自从我们自己构建GCC以来，这感觉很奇怪。但是，一切似乎都可以正常工作，因此这只是一个不便。
获取crosstool-NG，进行配置和构建：
git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
git checkout a6580b8e8b55345a5a342b5bd96e42c83e640ac5
export CT_PREFIX="$(pwd)/.build/install"
export PATH="/usr/lib/ccache:${PATH}"
./bootstrap
./configure --enable-local
make -j `nproc`
./ct-ng x86_64-unknown-linux-gnu
./ct-ng menuconfig
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
构建过程大约需要三十分钟到两个小时。
我可以看到的唯一强制性配置选项是使其与您的主机内核版本匹配，以使用正确的内核标头。查找您的主机内核版本：
uname -a
这告诉我：
4.15.0-34-generic
所以menuconfig我这样做：
Operating System
Version of linux
所以我选择：
4.14.71
这是第一个相同或更旧的版本。它必须更旧，因为内核是向后兼容的。
在.config我们与生成./ct-ng x86_64-unknown-linux-gnu具有：
CT_GLIBC_V_2_27=y
要更改此设置，menuconfig请执行以下操作：
C-library
Version of glibc
保存.config，然后继续构建。
或者，如果你想使用自己的glibc的来源，例如使用的glibc从最新的git，继续像这样：
Paths and misc options
Try features marked as EXPERIMENTAL：设置为true
C-library
Source of glibc
Custom location：是的
Custom location
Custom source location：指向包含您的glibc源代码的目录
glibc被克隆为：
git clone git://sourceware.org/git/glibc.git cd glibc git checkout glibc-2.28
构建所需的工具链后，请使用以下工具进行测试：
#!/usr/bin/env bash
set -eux
install_dir="${CT_PREFIX}/x86_64-unknown-linux-gnu"
PATH="${PATH}:${install_dir}/bin" \
x86_64-unknown-linux-gnu-gcc \
-Wl,--dynamic-linker="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib/ld-linux-x86-64.so.2" \
-Wl,--rpath="${install_dir}/x86_64-unknown-linux-gnu/sysroot/lib" \
-v \
-o test_glibc.out \
test_glibc.c \
-pthread \
;
ldd test_glibc.out
./test_glibc.out
除了现在使用了正确的运行时对象外，其他所有内容似乎都与安装程序1一样工作：
COLLECT_GCC_OPTIONS=/home/ciro/crosstool-ng/.build/install/x86_64-unknown-linux-gnu/bin/../x86_64-unknown-linux-gnu/sysroot/usr/lib/../lib64/crt1.o
如下所述，使用crosstool-NG似乎不可能。
如果您只是重建；
env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`
然后会考虑您对自定义glibc源位置所做的更改，但是它会从头开始构建所有内容，因此无法用于迭代开发。
如果这样做：
./ct-ng list-steps
它很好地概述了构建步骤：
Available build steps, in order: - companion_tools_for_build - companion_libs_for_build - binutils_for_build - companion_tools_for_host - companion_libs_for_host - binutils_for_host - cc_core_pass_1 - kernel_headers - libc_start_files - cc_core_pass_2 - libc - cc_for_build - cc_for_host - libc_post_cc - companion_libs_for_target - binutils_for_target - debug - test_suite - finish Use "" as action to execute only that step. Use "+ " as action to execute up to that step. Use " +" as action to execute from that step onward.
因此，我们看到glibc步骤与多个GCC步骤交织在一起，最显着的libc_start_files是之前的步骤cc_core_pass_2，这可能是和一起最昂贵的步骤cc_core_pass_1。
为了只构建一个步骤，必须首先.config在初始构建的选项中设置“保存中间步骤” ：
Paths and misc options
Debug crosstool-NG
Save intermediate steps
然后您可以尝试：
env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`
但不幸的是，+如以下提到的那样需要：https : //github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536
但是请注意，在中间步骤重新启动会将安装目录重置为其在该步骤中的状态。即，您将拥有一个重建的libc-但没有使用此libc构建的最终编译器（因此也没有像libstdc ++这样的编译器库）。
基本上仍然会使重建速度太慢，无法进行开发，而且我不解决如何在不修补crosstool-NG的情况下克服这一问题。
此外，从libc步骤开始似乎并没有从再次复制源代码Custom source location，这进一步使该方法不可用。
如果您也对C ++标准库感兴趣，那么这是一个额外的好处：如何编辑和重建GCC libstdc ++ C ++标准库源代码？
你能考虑使用Nix http://nixos.org/nix/吗？
Nix支持多用户包管理:多个用户可以安全地共享一个通用的Nix商店,不需要拥有root权限来安装软件,并且可以安装和使用不同版本的软件包.
京公网安备 11010802040832号 | 京ICP备19059560号-6 