单个主机上有多个glibc库

时间：2009-05-11 08:20:37

标签： linux gcc glibc

单个主机上的多个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而不是从我放置它们的地方开始？

由于

11 个答案:

答案 0 :(得分：196)

很有可能在同一个系统上有多个版本的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）和{{1} }选项将“烘焙”路径以将-dynamic-linker更正为应用程序。

如果您无法重新链接ld-linux.so.2应用程序（例如，因为它是第三方二进制文件），并非所有内容都丢失，但它会变得更加棘手。一种解决方案是为其设置适当的myapp环境。另一种可能性是使用rtldi和binary editor。

答案 1 :(得分：35)

这个问题很老，其他答案都很陈旧。 ＆＃34;受雇俄语的答案非常好且信息丰富，但只有拥有源代码才有效。如果你不这样做，那么当时的替代方案就非常棘手。幸运的是，现在我们使用patchelf对这个问题有一个简单的解决方案（正如他的一个回复中所评论的那样）。您所要做的就是：

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

之后，你可以执行你的文件：

$ ./myapp

谢天谢地，无需chroot或手动编辑二进制文件。但是，如果您不确定自己在做什么，请记住在修补二进制文件之前备份它，因为它会修改您的二进制文件。在对其进行修补后，您无法将旧路径恢复为解释器/ rpath。如果它不起作用，你必须继续修补它，直到找到实际工作的路径......好吧，它不一定是试错过程。例如，在OP的示例中，他需要GLIBC_2.3，因此您可以使用strings轻松找到哪个lib提供该版本：

$ 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的情况下产生错误。

＆＃34; patchelf＆＃34;适用于尝试运行程序时可能遇到的许多不同问题，与这两个问题有关。例如，如果你得到：ELF file OS ABI invalid，可以通过设置一个新的加载器（命令的--set-interpreter部分）来修复它，因为我解释了here。另一个示例是当您运行存在且可执行的文件时获取No such file or directory的问题，例如here。在这种特殊情况下，OP缺少指向加载程序的链接，但在您的情况下，您可能没有root权限并且无法创建链接。设置新的翻译可以解决您的问题。

感谢受雇的俄罗斯人和Michael Pankov的见解和解决方案！

答案 2 :(得分：17)

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

LD_PRELOAD='mylibc.so anotherlib.so' program

请参阅：the Wikipedia article

答案 3 :(得分：7)

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

让我们采取简单的措施：我有新的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加载动态库。

这是使用选择（非系统默认）库调用可执行文件的方法。

答案 4 :(得分：6)

你能考虑使用Nix http://nixos.org/nix/吗？

  

Nix支持多用户包管理：多个用户可以共享   常见的Nix商店安全，不需要拥有root权限   安装软件，并可以安装和使用不同版本的   封装

答案 5 :(得分：4)

设置1：在没有专用GCC的情况下编译自己的glibc并使用它

此设置可能有效并且快速，因为它不会重新编译整个GCC工具链，而只是glibc。

但是它不可靠，因为它使用glibc提供的主机C运行时对象，例如crt1.o，crti.o和crtn.o。在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`

设置1：验证版本

test_glibc.c 

#define _GNU_SOURCE
#include <assert.h>
#include <gnu/libc-version.h>
#include <stdatomic.h>
#include <stdio.h>
#include <threads.h>

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.
     * https://stackoverflow.com/questions/56810/how-do-i-start-threads-in-plain-c/52453291#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

设置1：修改glibc

现在让我们用以下命令修改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
    <http://www.gnu.org/licenses/>.  */

+#include <stdio.h>
+
 #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上测试。

设置2：crosstool-NG原始设置

这是设置1的替代方法，它是我迄今为止所实现的最正确的设置：据我观察，一切都是正确的，包括C运行时对象，例如crt1.o，{{1 }}和crti.o。

在此设置中，我们将编译使用所需glibc的完整专用GCC工具链。

此方法的唯一缺点是构建将花费更长的时间。但是我不会冒任何减少生产设置的风险。

crosstool-NG是一组脚本，可以为我们下载并编译所有内容，包括GCC，glibc和binutils。

是的，GCC构建系统太糟糕了，为此我们需要一个单独的项目。

此设置并不完美，因为crosstool-NG does not support building the executables without extra -Wl flags自我们构建GCC以来感觉很奇怪。但这一切似乎都可行，所以这只是一个不便。

获取crosstool-NG，对其进行配置和构建：

crtn.o

构建大约需要三十分钟到两个小时。

我可以看到的唯一强制性配置选项是使其与您的主机内核版本匹配，以使用正确的内核头文件。使用以下命令查找主机内核版本：

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

是第一个相同或更低的版本。它必须更旧，因为内核是向后兼容的。

设置2：可选配置

我们用4.14.71 生成的.config具有：

./ct-ng x86_64-unknown-linux-gnu

要更改此设置，请在CT_GLIBC_V_2_27=y 中执行以下操作：

  • menuconfig
  • C-library

保存Version of glibc，然后继续构建。

或者，如果您想使用自己的glibc来源，例如要从最新的git使用glibc，请继续进行like this：

  • .config
    • Paths and misc options：设置为true
  • Try features marked as EXPERIMENTAL
    • C-library
      • Source of glibc：说是
      • Custom location
        • Custom location：指向包含您的glibc源代码的目录

glibc的克隆位置为：

Custom source location

设置2：进行测试

一旦构建了所需的工具链，请使用以下工具进行测试：

git clone git://sourceware.org/git/glibc.git
cd glibc
git checkout glibc-2.28

一切似乎都和安装程序1一样，除了现在使用了正确的运行时对象：

#!/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

设置2：有效的glibc重新编译尝试失败

使用crosstool-NG似乎无法实现，如下所述。

如果您只是重新构建； 

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

然后会考虑您对自定义glibc源位置所做的更改，但它会从头开始构建所有内容，因此无法用于迭代开发。

如果我们这样做：

env -u LD_LIBRARY_PATH time ./ct-ng build CT_JOBS=`nproc`

它很好地概述了构建步骤：

./ct-ng list-steps

因此，我们看到glibc步骤与多个GCC步骤交织在一起，最明显的是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 "<step>" as action to execute only that step. Use "+<step>" as action to execute up to that step. Use "<step>+" as action to execute from that step onward. 在libc_start_files之前，这可能是与cc_core_pass_2一起最昂贵的步骤。

要仅构建一个步骤，必须首先在cc_core_pass_1选项中为初始构建设置“保存中间步骤”：

  • .config
    • Paths and misc options
      • Debug crosstool-NG

然后您可以尝试：

Save intermediate steps

但不幸的是，https://github.com/crosstool-ng/crosstool-ng/issues/1033#issuecomment-424877536

提到了env -u LD_LIBRARY_PATH time ./ct-ng libc+ -j`nproc`
  

但是请注意，在中间步骤重新启动会将安装目录重置为其在该步骤中的状态。也就是说，您将拥有一个重建的libc-但没有使用该libc构建的最终编译器（因此也没有像libstdc ++这样的编译器库）。

并且基本上仍然使重建速度太慢而无法进行开发，而且我不明白如何在不修补crosstool-NG的情况下克服这一问题。

此外，从+步骤开始，似乎没有从libc再次复制源代码，进一步使该方法不可用。

奖金：stdlibc ++

如果您还对C ++标准库感兴趣，那么将获得奖励：How to edit and re-build the GCC libstdc++ C++ standard library source?

答案 6 :(得分：1)

如果仔细查看第二个输出，可以看到使用了库的新位置。也许仍有缺少库是glibc的一部分。

我还认为您的程序使用的所有库都应该针对该版本的glibc进行编译。如果您可以访问程序的源代码，那么新的编译似乎是最佳解决方案。

答案 7 :(得分：1)

＆＃34;雇用俄语＆＃34;是最好的答案，我认为所有其他建议的答案可能无效。原因很简单，因为首次创建应用程序时，所需的所有API都在编译时解析。使用＆＃34; ldd＆＃34;你可以看到所有静态链接的依赖项：

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还会加载许多其他动态库，例如（对于firefox），加载了许多＆＃34; glib＆＃34; - 标记的库（即使静态链接也没有）：

 /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

因此，这意味着不同版本的＆＃34;库＆＃34;存在于一个系统中 - 这不是问题，因为它是同一个文件，并且当应用程序具有多个版本依赖项时它将提供兼容性。

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

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

最好的选择是chroot（简要提到ER）：但为此你需要重新创建原始二进制执行的整个环境 - 通常从/ lib，/ usr / lib /，/ usr / lib /开始x86等您可以使用＆＃34; Buildroot＆＃34;或YoctoProject，或者只使用现有Distro环境中的tar。 （像Fedora / Suse等）。

答案 8 :(得分：1)

我不确定问题是否仍然存在，但是还有另一种解决问题的方法：Docker。可以安装源分发版（用于开发的分发版）的几乎空的容器，然后将文件复制到容器中。这样，您无需创建chroot所需的文件系统。

答案 9 :(得分：1)

@msb提供了一个安全的解决方案。

我在只有import tensorflow as tf的{​​{1}}的conda环境中执行CentOS 6.5时遇到了这个问题。 

glibc-2.12

我想提供一些细节：

首先将ImportError: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /home/ 安装到您的主目录：

glibc

第二，按照相同的方式安装patchelf;

第三，修补您的Python：

mkdir ~/glibc-install; cd ~/glibc-install
wget http://ftp.gnu.org/gnu/glibc/glibc-2.17.tar.gz
tar -zxvf glibc-2.17.tar.gz
cd glibc-2.17
mkdir build
cd build
../configure --prefix=/home/myself/opt/glibc-2.17  # <-- where you install new glibc
make -j<number of CPU Cores>  # You can find your <number of CPU Cores> by using **nproc** command
make install

如@msb

所述

现在我可以在[myself@nfkd ~]$ patchelf --set-interpreter /home/myself/opt/glibc-2.17/lib/ld-linux-x86-64.so.2 --set-rpath /home/myself/opt/glibc-2.17/lib/ /home/myself/miniconda3/envs/tensorflow/bin/python 中使用tensorflow-2.0 alpha。

ref：https://serverkurma.com/linux/how-to-update-glibc-newer-version-on-centos-6-x/

答案 10 :(得分：0)

当我想在Ubuntu精确（glibc-2.15）上运行chrome浏览器时，我得到了 （典型的）消息＆＃34; ... libc.so.6：版本`GLIBC_2.19＆＃39;没找到...＆＃34;。 我考虑过这样一个事实，即永久性地不需要文件，但仅限于开始。 所以我收集了浏览器和sudo所需的文件并创建了一个mini-glibc-2.19- 环境，启动浏览器然后将原始文件复制回来 再次。所需的文件在RAM中，原始的glibc是相同的。

as root
the files (*-2.15.so) already exist

mkdir -p /glibc-2.19/i386-linux-gnu 

/glibc-2.19/ld-linux.so.2 -> /glibc-2.19/i386-linux-gnu/ld-2.19.so
/glibc-2.19/i386-linux-gnu/libc.so.6 -> libc-2.19.so
/glibc-2.19/i386-linux-gnu/libdl.so.2 -> libdl-2.19.so
/glibc-2.19/i386-linux-gnu/libpthread.so.0 -> libpthread-2.19.so

mkdir -p /glibc-2.15/i386-linux-gnu 

/glibc-2.15/ld-linux.so.2 -> (/glibc-2.15/i386-linux-gnu/ld-2.15.so)
/glibc-2.15/i386-linux-gnu/libc.so.6 -> (libc-2.15.so)
/glibc-2.15/i386-linux-gnu/libdl.so.2 -> (libdl-2.15.so)
/glibc-2.15/i386-linux-gnu/libpthread.so.0 -> (libpthread-2.15.so)

运行浏览器的脚本：

#!/bin/sh
sudo cp -r /glibc-2.19/* /lib
/path/to/the/browser &
sleep 1
sudo cp -r /glibc-2.15/* /lib
sudo rm -r /lib/i386-linux-gnu/*-2.19.so
相关问题
最新问题