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 ...）。我的configure和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个场景：

SCENARIO1。使用系统的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

SCENARIO2。将$ 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。我不太确定。

我的问题：

您能否为我解释上面的怪异的以及 not a dynamic executable 后面的以下行？
您能否与我分享正确构建glibc（GOAL1）并使用该glibc（GOAL2）构建软件的步骤？
接下来我可以做些什么来解决上述情况？

谢谢。

Answer 1

当您链接ELF时，ldso的绝对路径是硬编码的。如果要使用其他标记，可以使用-Wl,--dynamic-linker=/path/to/ldso标记覆盖它。这条路径是绝对的，所以如果你试图将你的本地glibc移动到其他地方，你链接的ELF将无法执行（错误如no such file）。由于系统在设计上必须在interpreter中有绝对路径，所以没有办法解决这个问题。

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

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

如果您真的非常想花时间亲自操作，请参考glibc wiki building your own glibc然后linking apps against that glibc。

在较新的系统

1 个答案: