我如何在Linux上以非root身份维护单独的（较新的）glibc / gcc /…堆栈

我们的计算集群运行的CentOS版本非常旧，带有旧的内核（2.6.18），当然还有旧的库和二进制文件。因为更新整个事情需要在所有节点上进行大量工作，所以这不是一个选择。

我正在尝试编译和使用需要C++11（因此需要更高版本的gcc（和/或clang）版本）的程序。因为我根本不想弄乱系统，所以我想以某些本地目录树中的非root用户身份进行操作。

问题是，这gcc需要glibc比机器上存在的机器更新的机器。因此，我需要保持一个独立的，新版本glibc在我的本地lib/所描述的树，可能是在这里。

我迷路的地方是如何将本地库的路径“硬编码”为所有所需的二进制文件，例如gcc，g++等等。将LD_LIBRARY_PATH设置为我的本地lib/树会导致所有系统二进制文件不再起作用（ELF file OS ABI invalid），因为它们要使用尚未针对其编译的new libm.so/ libc.so。

所以，把它包起来：什么是保持一个较新的，局部的开发堆栈（含适当的方式glibc，gcc并行等）旧系统没有乱搞的根源？

附带提出一个问题：设置LD_LIBRARY_PATH作为SE的解决方案发布到整个SE上glibc。对我来说，当我尝试执行任何系统二进制文件（如ls）时，都会导致上述错误。怎么来的？我做错了什么还是预期的行为？

您基本上有三个选择：

1. 在您的库周围使用包装器，该包装器将进行LD_LIBRARY_PATH适当设置，然后执行所需的库-类似于：

   #!/bin/sh
   export LD_LIBRARY_PATH="path/goes/here"
   exec "$@"
   

2. 与-rpath（-Wl,rpath）链接，将动态链接程序的搜索路径添加到二进制文件中（另请参见SO答案 -它还提到了包装器）。

3. 你不会喜欢阅读这一个：更新您的群集（注意，“你”的强调）。它必须一天或一天​​完成，所以为什么今天不这样做。在大多数情况下，“不可行”有点强。其他用户可能也有相同的问题。

至于有问题的旧二进制文件-二进制文件中嵌入了它们首选的动态链接器。而且旧的动态链接器不了解新的ABI。尝试像这样调用二进制文件：path/to/your/ld-linux-<arch>.so binary。

构建GCC：您始终可以尝试CFLAGS在GCC的构建环境中导出-但我敢肯定它们会传播。各种发行版本的构建脚本可能会为您提供一些线索（例如：对于openSUSE，请查看.spec文件中的 1880行）。