使用 gcc 禁止默认库路径答案

【问题标题】：Inhibit default library paths with gcc使用 gcc 禁止默认库路径
【发布时间】：2011-11-21 13:24:30
【问题描述】：

有没有办法禁止使用 gcc 进行默认库路径搜索？ -nostdinc 为包含路径搜索执行此操作，但 -nostdlib，无论是遗漏还是设计，仅禁止 -lc -lgcc 等，但不禁止库搜索路径。

【问题讨论】：

为什么不直接使用编译器，编译 :) 并在链接步骤中直接使用ld？
@Jens：这意味着在 C 或 shell 脚本中重新实现整个编译器驱动程序行为（“gcc”命令）。并非不可能，但要完成 gcc 应该已经能够做到的事情，还需要做相当多的工作。
How to stop gcc from passing -L with standard library paths to the linker 的可能重复项

标签： c gcc

【解决方案1】：

你应该可以使用 spec files 来做到这一点（尽管摆弄这些对我来说似乎是一种黑暗艺术......）。

如果您查看gcc -dumpspecs 的输出，link_command 规范就是构建调用的实际命令的规范。挖掘它引用的其他一些规范，link_libgcc 规范，通常定义为（至少对于本机编译器）：

*link_libgcc:
%D

是罪魁祸首：

%D

为 GCC 认为可能包含启动文件的每个目录转储一个 -L 选项。如果目标支持多库，那么当前的多库目录将被添加到这些路径中的每一个。

您可以通过创建一个替换您选择的路径的文件（例如my.specs）来覆盖它：

*link_libgcc:
-L/foo/bar -L/blah/blah

然后将-specs=my.specs 传递给gcc。

【讨论】：

哇，我想你找到了“罪魁祸首”！最重要的是，gcc 似乎接受/dev/fd/3 和“此处文件”（3-specs 的参数，因此您甚至可以不使用显式临时文件。这应该可以解决我正在做的包装类型的许多其他问题。
顺便说一句，如果这能解决我的所有需求，我会为这个问题添加一个赏金并将其分配给你。
谢谢 - 我很高兴它有帮助！
是的，不知何故，我从未意识到 (1) 这些路径在规范文件中的确切位置，因为它们隐藏在 %D 中，而不是硬编码， (2) 你可以传递一个只覆盖一些东西的部分规范文件，而不必制作一个定义所有内容的完整规范文件。您的回答极大地扩展了我对如何自定义 gcc 行为的理解。

【解决方案2】：

假设底层加载器是ld，您可能能够重定向它的整个加载路径

--sysroot=directory

（我不记得您必须使用哪个选项将加载程序参数传递给 gcc，但有一个...）

您可以让“目录”是虚假的，找不到任何库，或者模仿您自己项目的目录布局。

【讨论】：

【解决方案3】：

设置LIBRARY_PATH 环境变量怎么样？

如果我正确理解了这个问题，您想要执行一些操作，例如强制链接器在默认路径之前查看本地库路径，这样您就可以显式设置该变量来控制顺序。

【讨论】：

【解决方案4】：

你可以尝试 -nodefaultlibs 来避免所有默认库，然后使用 -L 和 -l 在你想要的目录中添加你想要的库。在命令行中使用 -L 选项指定的目录应优先于默认目录。

【讨论】：

它不会删除库路径，只是删除库。并且添加回目录也无济于事，因为配置脚本仍然会很高兴地在旧的默认路径中找到库并尝试使用它们...
在 gcc 命令行中由 -L 指定的目录中是否有一个库被默认目录中的目录忽略，或者您的配置脚本是否在拾取它们？
我的问题是使用现有 gcc 安装和包装脚本针对备用库生态系统构建程序。只要有默认的搜索路径，各种程序的配置脚本就可以找到属于宿主库生态系统的库，并愉快地尝试使用它们，但后来由于不兼容而失败......
R，您的问题是关于 gcc 以及它在哪里搜索库，但您现在谈论的是配置脚本。我的意思是，如果您在 gcc 命令行上使用 -L 列出您的备用目录，那么 gcc 将使用这些目录。如果这些备用目录中没有任何备用库，则 gcc 将使用默认目录。您是否尝试让链接失败？
我并没有尝试使用 gcc 来解决特定问题，而是尝试包装 gcc 来解决一般问题。我的问题是为了解决一般问题。