☰

为什么LFS和CLFS改变用于查找动态链接器的路径？

tag-icon • tag-icon gcc lfs
为什么LFS和CLFS改变用于查找动态链接器的路径？

两个都线性FS和CLFS在构建之前对 GCC 源应用补丁。

CLFS 补丁比 LFS 补丁涉及更多一些，但它们的共同点是更改用于查找动态链接器的路径。在本例中，它被移动到将要构建新版本 glibc 的位置。

因为，至少在 CLFS 的情况下，您正在构建一个交叉工具链，并且可能您无法在构建机器上运行使用此链构建的任何内容，所以 GCC 让程序查找动态链接器有什么区别。这不是一个永远不会发生的运行时操作吗？另外，如果您使用此 GCC 构建了一个需要共享库的二进制文件，并尝试在目标上运行它，那么动态链接器的路径现在不会是错误的吗？

另外，(C)LFS 让您修改为STANDARD_STARTFILE_PREFIX_X指向$INSTALL_PATH/tools/lib/.当/如果您指定时，这些路径不会被检查吗--with-sysroot？使用--with-sysrootif 我检查构建 GCC 后，--preint-search-dirs除了引用 prefix 或--with-sysroot.

答案1

您链接的页面用于构建临时工具链，然后使用该工具链构建 LFS 第 6 章中的最终系统。这GCC 第 6 章编译时没有任何补丁。临时工具链中的补丁仅用于允许进一步编译软件包，而与主机系统使用的工具无关。

答案2

(C)LFS 非常努力地构建一个与构建机器尽可能少的联系的 Linux 系统。因此，某些步骤可能显得不必要、多余或做作。以下是解决主要问题的 CLFS 流程（的子集）：

  1. Ch5: 交叉 binutils
  2. Ch5：第一次跨海湾合作委员会
  3. Ch5：Glibc（可由交叉编译器和目标本机编译器使用），安装时前缀为/tools
  4. Ch5：第二遍交叉 gcc。此处应用动态链接器路径补丁来指向/tools，这是一个符号链接，$CLFS/tools其中 $CLFS 是目标文件系统的根目录。
  5. Ch6：使用第二遍交叉 gcc 构建一堆目标本机的新工具，其中包括在目标上本机运行的 gcc 版本。此列表中明显缺少 glibc 的另一个副本。这不是必需的，因为之前构建的目前就可以了。
  6. Ch10：引导/chroot 到目标系统，该系统现在/tools与您的构建计算机位于同一位置。这允许较早构建（作为本机）的工具访问动态链接器。现在你将再次制作 glibc 但这次它将进入标准/usr（而不是/tools/usr）

问题的根源与动态链接器路径以及它相对于构建机器出现的事实有关。答案基本上是OP（我）没有考虑/tools 之间如何存在符号链接，${CLFS}/tools并且应用了补丁以使/tools 成为链接器的根路径。

我对这个问题没有答案STANDARD_STARTFILE_PREFIX_X。

相关内容