单个主机上有多个 glibc 库

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

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

使用LD_PRELOAD： 将库放在 man lib 目录之外的某个位置，然后运行：

LD_PRELOAD='mylibc.so anotherlib.so' program

参见：维基百科文章

在同一个系统上有多个版本的glibc是很有可能的（我们每天都这样做）。

但是，您需要知道 glibc 由许多部分（200+ 共享库）组成，这些部分都必须匹配。其中一个部分是 ld-linux.so.2，它必须与 libc.so.6 匹配，否则你会看到你所看到的错误。

ld-linux.so.2 的绝对路径在链接时被硬编码到可执行文件中，链接完成后不能轻易更改（更新：可以使用 patchelf 完成;请参阅下面的答案）。

要构建一个可执行文件，可以与新的 glibc 一起使用，请执行以下操作：

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

链接器选项将使运行时加载程序搜索库（因此您不必在运行它之前进行设置），并且该选项将“烘焙”路径以更正到应用程序中。-rpath/path/to/newglibcLD_LIBRARY_PATH-dynamic-linkerld-linux.so.2

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

更新：或者您可以在现有二进制文件上使用 patchelf 将它们重定向到备用 libc。

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

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

“受雇的俄语”是最好的答案之一，我认为所有其他建议的答案可能都行不通。原因很简单，因为当一个应用程序第一次创建时，它需要的所有 API 都在编译时解析。使用 “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 也会加载许多其他动态库，例如（对于 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

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

这个问题很老，其他答案也很老。“Employed Russian”的回答非常好，内容丰富，但只有在你有源代码的情况下才有效。如果你不这样做，当时的替代方案是非常棘手的。幸运的是，现在我们有一个简单的解决方案来解决这个问题（正如他的一个回复中所评论的那样），使用 patchelf。您所要做的就是：

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

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

$ ./myapp

谢天谢地，无需或手动编辑二进制文件。但是，如果您不确定自己在做什么，请记住在修补二进制文件之前备份它，因为它会修改您的二进制文件。修补后，无法将旧路径还原为 interpreter/rpath。如果它不起作用，您将不得不继续修补它，直到找到真正有效的路径......好吧，这不一定是一个反复试验的过程。例如，在 OP 的例子中，他需要 ，所以你可以很容易地找到哪个库提供该版本，使用：chrootGLIBC_2.3strings

$ 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，因为它有正在使用的版本，所以我们知道我们可以使用该路径的二进制文件。如果遇到分段错误，请阅读末尾的注释。myapppatchelf

当您尝试在 linux 中运行二进制文件时，二进制文件会尝试加载链接器（又名加载器，又名解释器），然后是库，它们都应该在路径和/或正确的位置。如果你的问题出在链接器上，并且你想找出你的二进制文件正在寻找的路径，你可以使用以下命令找出答案：

$ readelf -l myapp | grep interpreter
  [Requesting program interpreter: /lib/ld-linux.so.2]                                                                                                                                                                                   

如果您的问题出在库上，则为您提供正在使用的库的命令是：

$ readelf -d myapp | grep Shared
$ ldd myapp 

这将列出您的二进制文件需要的库，但您可能已经知道有问题的库，因为它们已经像 OP 的情况一样产生了错误。执行 patchelf 后，可能会发生仍然无法正常工作的情况，当您运行它时，它会列出具有混合路径的库，其中一些是您设置的路径，另一些是原始系统路径。那是因为你的路径没有这些库。 将在您设置的路径中搜索库，但如果它不存在，它仍会在其他系统位置中查找它。在这种情况下，如果您在某处缺少库，只需将其复制到您选择的库，它应该可以工作。myappldd myapprpathrpath

“Patchelf”适用于您在尝试运行程序时可能遇到的许多不同问题，与这两个问题有关。例如，如果你得到：，它可以通过设置一个新的加载程序（命令的一部分）来修复，正如我在这里解释的那样。另一个示例是当您运行存在且可执行的文件时获取的问题，如此处所示。在这种特殊情况下，OP 缺少指向加载器的链接，但也许在您的情况下，您没有 root 访问权限并且无法创建链接。设置新的解释器将解决您的问题。ELF file OS ABI invalid--set-interpreterNo such file or directory

感谢 Employed Russian 和 Michael Pankov 的见解和解决方案！

---

分段错误注意事项：您可能处于使用多个库的情况，其中大多数都可以，但有些则不行;然后你把它放到一个新的目录，你会得到分段错误。当你的二进制文件时，你会改变几个库的路径，即使有些库最初在不同的路径上。请看下面我的例子：myapppatchelfpatchelf

$ ldd myapp
./myapp: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./myapp)
./myapp: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./myapp)
        linux-vdso.so.1 =>  (0x00007fffb167c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9a9aad2000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9a9a8ce000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9a9a6af000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f9a9a3ab000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9a99fe6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9a9adeb000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9a99dcf000)

请注意，大多数库都在 中，但有问题的库 （） 在 上。在我 patchelf 指向 之后，我得到了分割错误。由于某种原因，库与二进制文件并不完全兼容。由于没有抱怨原始库，我将它们从 复制到 ，我也从那里复制。然后我把它打到，现在可以工作了。如果你的二进制文件使用不同的库，并且你有不同的版本，你可能会发生无法解决你的情况。:(但如果可能的话，混合库可能是方法。这并不理想，但也许它会起作用。祝你好运！/lib/x86_64-linux-gnu/libstdc++.so.6/usr/lib/x86_64-linux-gnumyapp/path/to/mylibsmyapp/lib/x86_64-linux-gnu//path/to/mylibs2libstdc++.so.6/path/to/mylibs/path/to/mylibs2myapp

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

让我们举个简单的例子：我有 newset 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 加载动态库。

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

当我想在 Ubuntu precise （glibc-2.15） 上运行 chromium 浏览器时，我得到了 （典型）消息“...libc.so.6：找不到版本“GLIBC_2.19”...”。 我考虑了这样一个事实，即文件不是永久需要的，而只是为了开始。 因此，我收集了浏览器和 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

我不确定这个问题是否仍然相关，但还有另一种解决问题的方法：Docker。可以安装一个几乎为空的 Source Distribution（用于开发的 Distribution）并将文件复制到容器中。这样你就不需要创建 chroot 所需的文件系统了。

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

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

但它并不可靠，因为它使用主机 C 运行时对象，例如 、 和 ，并由 glibc 提供。这在以下位置提到： https://sourceware.org/glibc/wiki/Testing/Builds?action=recall&rev=21#Compile_against_glibc_in_an_installed_location 这些对象做了 glibc 所依赖的早期设置，所以如果事情以美妙而微妙的方式崩溃，我不会感到惊讶。crt1.ocrti.ocrtn.o

有关更可靠的设置，请参阅下面的设置 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输出确认我们刚刚构建的 AND 库实际上按预期使用：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，而不是主机。

在 Ubuntu 18.04 上测试。

设置 2：crosstool-NG 原始设置

这是设置 1 的替代方法，也是我迄今为止实现的最正确的设置：据我所知，一切都是正确的，包括 C 运行时对象，例如 、 和 。crt1.ocrti.ocrtn.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`

构建大约需要 30 分钟到 2 小时。

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

uname -a

它向我展示了：

4.15.0-34-generic

所以在我做：menuconfig

• Operating System
  • Version of linux

所以我选择：

4.14.71

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

设置 2：可选配置

我们生成的具有：.config./ct-ng x86_64-unknown-linux-gnu

CT_GLIBC_V_2_27=y

要改变这一点，请执行以下操作：menuconfig

• C-library
• Version of glibc

保存 ，然后继续生成。.config

或者，如果你想使用你自己的 glibc 源代码，例如从最新的 git 中使用 glibc，请按如下方式进行：

• 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

设置 2：测试

一旦你建立了你想要的工具链，就用以下方法进行测试：

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

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

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 "<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.

因此，我们看到有 glibc 步骤与几个 GCC 步骤交织在一起，最明显的是 之前 ，这可能是与 一起最昂贵的步骤。libc_start_filescc_core_pass_2cc_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 的情况下克服这个问题。

此外，从该步骤开始似乎没有再次复制源，进一步使此方法无法使用。libcCustom source location

奖励：stdlibc++

如果您也对 C++ 标准库感兴趣，那么奖励：如何编辑和重新构建 GCC libstdc++ C++ 标准库源代码？

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

当我在只有 .import tensorflow as tfCentOS 6.5glibc-2.12

ImportError: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by /home/

我想提供一些细节：

首先安装到您的主目录：glibc

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

其次，按照相同的方式安装 patchelf;

第三，修补你的 Python：

[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

正如@msb所提到的

现在我可以在 .tensorflow-2.0 alphaCentOS 6.5

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