在新系统上构建较旧的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）

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

$ 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. 接下来我该怎么做才能解决上述两种情况？

谢谢。

Answer 1

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

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

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

如果您真的想花时间手动完成这一切，您应该参考glibc wiki来构建您自己的 glibc，然后将应用程序链接到该 glibc。