单个主机上有多个glibc库

单个主机上有多个glibc库

我的linux(SLES-8)服务器目前有glibc-2.2.5-235,但是我有一个程序不能在这个版本上运行,需要glibc-2.3.3。

是否有可能在同一主机上安装多个glibcs​​?

这是我在旧的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) 

于是我创build了一个名为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的绝对path在链接时被硬编码到可执行文件中,链接完成后不能轻易改变。

要构build一个可以使用新的glibc的可执行文件,请执行以下操作:

 g++ main.o -o myapp ... \ -Wl,--rpath=/path/to/newglibc \ -Wl,--dynamic-linker=/path/to/newglibc/ld-linux.so.2 

-rpath连接器选项将使运行时加载器在/path/to/newglibcsearch库(因此在运行之前不需要设置LD_LIBRARY_PATH ),而-dynamic-linker选项将“烘烤”path来更正ld-linux.so.2进入应用程序。

如果您不能重新链接myapp应用程序(例如,因为它是第三方二进制文件),并不是所有的都会丢失,但是会变得棘手。 一个解决scheme是为它设置合适的chroot环境。 另一种可能是使用rtldi和二进制编辑器 。

使用LD_PRELOAD:把你的库放在man lib目录的某个地方并运行:

 LD_PRELOAD='mylibc.so anotherlib.so' program 

请参阅: 维基百科文章

你可以考虑使用Nix http://nixos.org/nix/

Nix支持多用户软件包pipe理:多个用户可以安全地共享一个通用的Nix存储,不需要具有root权限来安装软件,并且可以安装和使用不同版本的软件包。

这个问题很老,这些答案很老。 “俄罗斯人的回答非常好,内容丰富,但幸运的是,现在我们有一个简单的解决scheme来解决这个问题(正如他的回复中所述),使用patchelf 。 你所要做的就是:

 $ ./patchelf --set-interpreter /path/to/newglibc/ld-linux.so.2 --set-rpath /path/to/newglibc/ myapp 

之后,你可以执行你的文件:

 $ ./myapp 

幸好没有必要chroot或编辑二进制文件。 但是如果你不确定你在做什么,记得在修补它之前备份你的二进制文件。 在你修补它后,你不能恢复到解释器/ rpath的旧path。 如果它不起作用,你将不得不修补它,直到你find实际工作的path…呃,它不一定是一个试错的过程。 例如,在OP的例子中,他需要GLIBC_2.3 ,所以你可以很容易地find哪个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没有他想要的版本,第二个应该输出GLIBC_2.3,因为它有myapp使用的版本,所以我们知道我们可以使用path。

感谢雇用俄罗斯和迈克尔潘科夫的洞察力和解决scheme!

如果仔细观察第二个输出,可以看到使用了库的新位置。 也许还有遗漏的库是glibc的一部分。

我也认为你的程序使用的所有库都应该针对该版本的glibc进行编译。 如果您有权访问该程序的源代码,则新的编译看起来是最好的解决scheme。

“就业俄罗斯”是最好的答案之一,我认为所有其他build议的答案可能无法正常工作。 原因很简单,因为当第一次创build应用程序时,所有需要的API都会在编译时被parsing。 使用“ldd”你可以看到所有的静态链接的依赖关系:

 ldd /usr/lib/firefox/firefox linux-vdso.so.1 => (0x00007ffd5c5f0000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f727e708000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f727e500000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f727e1f8000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f727def0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f727db28000) /lib64/ld-linux-x86-64.so.2 (0x00007f727eb78000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f727d910000) 

但在运行时,firefox也会加载许多其他的dynamic库,例如(对于firefox)有很多“glib”标签的库加载(即使静态链接没有):

  /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2.2.2 /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0 /usr/lib/x86_64-linux-gnu/libavahi-glib.so.1.0.2 

很多时候,你可以看到一个版本的名字被软链接到另一个版本。 例如:

 lrwxrwxrwx 1 root root 23 Dec 21 2014 libdbus-glib-1.so.2 -> libdbus-glib-1.so.2.2.2 -rw-r--r-- 1 root root 160832 Mar 1 2013 libdbus-glib-1.so.2.2.2 

因此,这意味着在一个系统中存在不同版本的“库” – 这不是问题,因为它是相同的文件,并且当应用程序具有多个版本依赖关系时它将提供兼容性。

因此,在系统层面上,所有库几乎相互依赖,只是通过操作LD_PRELOAD或LD_LIBRARY_PATH来改变库加载优先级将无济于事 – 即使它可以加载,运行时也可能会崩溃。

http://lightofdawn.org/wiki/wiki.cgi/-wiki/NewAppsOnOldGlibc

最好的select是chroot(简要地提到ER):但是为此,您将需要重新创build原始二进制执行的整个环境 – 通常从/ lib,/ usr / lib /,/ usr / lib / x86开始。您既可以使用“Buildroot”,也可以使用YoctoProject,或者从现有的Distro环境中使用tar。 (比如Fedora / Suse等)。

首先,每个dynamic链接程序最重要的依赖是链接器。 所有库都必须匹配链接器的版本。

让我们以简单的例子:我有新的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使用链接可执行文件与所有dynamic库。

其余的文件是真正的库,它们连同链接器都必须复制到centos的某个地方。

假设所有的库和连接器都在“/ mylibs”目录中。

ld-linux-x86-64.so.2 – 正如我已经说过的 – 是链接器。 这不是dynamic库,而是静态可执行文件。 你可以运行它,看看它甚至有一些参数,例如–library-path(我会回到它)。

在Linux上,dynamic链接的程序可能只是由它的名字,例如

 /bin/ldc2 

Linux将这样的程序加载到RAM中,并检查为其设置了哪个链接程序。 通常,在64位系统上,它是/lib64/ld-linux-x86-64.so.2(在您的文件系统中,它是与真实可执行文件的符号链接)。 然后linux运行链接器,并加载dynamic库。

你也可以改变这一点,做这样的伎俩:

 /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加载dynamic库。

这是通过select(不是系统默认)库来调用可执行文件的方法。