在较新的系统上构建较旧的 GLIBC

Question

我有一个问题，我希望这里的一些专家可以帮助我:) 我的目标很简单：(GOAL1) 在新系统上构建旧 glibc，(GOAL2) 构建可以在旧 glibc 上运行的旧软件。我在gcc4.9，glibc2.19，amd64系统。我确实在我的系统上编译了 glibc2.14 和 gcc4.7.3。

（约定：/path/to/libc2.14_dir = $LIBC214, /path/to/gcc4.7.3 = $GCC473）

我正在尝试使用新建的 glibc2.14 编译 bash4.2.53（以及其他软件 coreutil、binutil、qt3.3...）。我的配置和制作看起来像这样：（我在对象/构建目录中）

$ cd /path/to/build/bash-4.2.53
$ CC=$GCC473/bin/gcc CXX=$GCC473/bin/g++ CPP=$GCC473/bin/cpp \
   /path/to/source/bash-4.2.53/configure \
   --prefix=/path/to/installation/bash-4.2.53
$ make all V=1 \
   CFLAGS="-Wl,--rpath=$LIBC214/lib -Wl,--dynamic-linker=$LIBC214/lib/ld-linux-x86-64.so.2" \
   CPPFLAGS="-Wl,--rpath=$LIBC214/lib -Wl,--dynamic-linker=$LIBC214/lib/ld-linux-x86-64.so.2" \
   CXXFLAGS="-Wl,--rpath=$LIBC214/lib -Wl,--dynamic-linker=$LIBC214/lib/ld-linux-x86-64.so.2" 

当在 bash4.2.53 build (object) 目录中完成 make 时，我尝试了 2 个场景：

场景 1。使用系统的libc2.19

$ ldd ./bash
   linux-vdso.so.1 (0x00007ffe677c3000)
   libtinfo.so.5 => $MY_PREBUILT_NCURSE/lib/libtinfo.so.5 (0x00007f5d108e3000)
   libdl.so.2 => $LIBC214/lib/libdl.so.2 (0x00007f5d106df000)
   libc.so.6 => $LIBC214/lib/libc.so.6 (0x00007f5d10354000)
   $LIBC214/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f5d10b0a000)

这条线很奇怪：$LIBC214/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f5d10b0a000)

$ $LIBC214/bin/ldd ./bash
   not a dynamic executable

场景 2。将 $LIBC214/bin 添加到我的 PATH，将 $LIBC214/lib 添加到我的 LD_LIBRARY_PATH

$ ldd ./bash
/bin/bash: $LIBC214/lib/libc.so.6: version `GLIBC_2.15' not found (required by /bin/bash)
$ export SHELL=$PWD/bash
$ ldd --version
/bin/bash: $LIBC214/lib/libc.so.6: version `GLIBC_2.15' not found (required by /bin/bash)
$ ldd ./bash
/bin/bash: $LIBC214/lib/libc.so.6: version `GLIBC_2.15' not found (required by /bin/bash)

据我所知，SCENARIO2 是运行命令的正确方式。我的假设是我错误地构建了 glibc2.14，它使用了/bin/bash，而后者又使用了 glibc2.19。我不太确定。

我的问题：

1. 能否请您为我解释一下上面的奇怪的行和输出的以下行not a dynamic executable？

2. 您能否分享一下正确构建 glibc (GOAL1) 和使用该 glibc (GOAL2) 构建软件的步骤？

3. 接下来我该怎么做才能解决上述 2 个场景？

谢谢。

Answer 1

当您链接 ELF 时，ldso 的绝对路径会被硬编码在其中。如果你想使用不同的，你可以使用-Wl,--dynamic-linker=/path/to/ldso 标志来覆盖它。这个路径是绝对的，所以如果你尝试将本地 glibc 移动到其他地方，你链接的 ELF 将无法执行（出现 no such file 之类的错误）。没有办法解决这个问题，因为根据设计，系统中必须有一个到 interpreter 的绝对路径。

你得到奇怪的not a dynamic executable 输出的原因是ldd 通过实际执行目标 ELF 并提取（通过调试挂钩）加载的库来工作。因此，当您尝试像这样使用 diff ldd 时，glibc 会感到困惑。如果你想要一个稳定的依赖列表器，你可以考虑pax-utils 项目中的lddtree 之类的东西（现在大多数发行版都捆绑了这个）。或直接在文件上运行readelf -d 并查看所有DT_NEEDED 条目。

尝试构建和维护自己的工具链（glibc、gcc 等）是一件非常麻烦的事情。除非您想为此投入大量时间，否则您真的应该使用像 crosstool-ng 这样的项目来为您管理它。这将允许您使用较旧的 glibc 构建完整的工具链，然后您可以使用它来构建您喜欢的任何随机包。

如果您真的想花时间手动完成这一切，您应该参考glibc wiki 获取building your own glibc，然后参考linking apps against that glibc。