当您使用 cc(1) 链接程序时，它将调用默认的链接器命令。例如，您的编译器版本可能已构建为在类 unix 平台上默认使用/usr/bin/ld。

有没有办法指定cc(1)(或c++(1))应该使用的不同链接器命令(例如，/usr/local/bin/ld 而不是 /usr/bin/ld)？我主要对 gcc 和 clang 感兴趣。

我不是在寻找涉及单独运行各种编译步骤(例如，预处理、编译、汇编、链接)的方法。

例如，我希望这样的东西可以完成这项工作:

env LD=/usr/local/bin/ld cc foo.c -o foo

但这对 gcc 或 clang 不起作用。当然，如果您有一个首先构建目标文件的 makefile，然后调用 ${LD} 进行链接(例如，env LD=/usr/local/bin/ld make)，它会起作用

更新(有一个可能的动机):使用与默认链接器不同的链接器轻松测试。例如，如果能够这样做就好了:

cc --linker=/usr/local/bin/ld foo.c -o foo

相反，您必须生成目标文件，运行 cc -v 找出 ld 的参数，手动运行 ld 你想要那些论点:

cc -c foo.c
cc -v foo.c -o /dev/null

现在查看链接器调用并手动复制/粘贴替换链接器和临时目标文件。像这样的东西(取自 fedora 23 测试的示例)，您将 /usr/libexec/gcc/x86_64-redhat-linux/5.3.1/collect2 替换为 /usr/local/bin/ld(尽管它与collect2不完全相同):

/usr/local/bin/ld -plugin /usr/libexec/gcc/x86_64-redhat-linux/5.3.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/lto-wrapper -plugin-opt=-fresolution=/tmp/jhein/ccM2XKIg.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o c /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1 -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../.. c.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/5.3.1/crtend.o /usr/lib/gcc/x86_64-redhat-linux/5.3.1/../../../../lib64/crtn.o

如您所见，这并不容易。请注意，在 gcc 信息页面中有关于 collect2 如何查找链接器程序的文档。但根据这些文档，它首先看起来不是环境变量或您可以在命令行上指定的内容(例如，--linker)。文档说它看起来首先是“硬编码链接器文件名”。如果该文档是正确的，要强制它不使用该链接器(即欺骗它)，您必须重命名默认链接器(例如，sudo mv/usr/bin/ld/usr/bin/ld. tmp-禁用).

更新 2:使用 -B 似乎足以满足我的需求。请参阅下面我发布答案的位置。我不能接受我自己的回答，但如果可以的话我会接受 - 它似乎很好地解决了这个问题。

最佳答案

-B 选项允许您为编译器将使用的可执行文件、库、包含文件和数据文件指定备用搜索路径。这适用于某些版本的 gcc [1] 和 clang(目前未记录 - 在至少 clang 3.7 和 3.8 的手册页中):

cc -B/usr/local/bin foo.c -o foo

请注意，这将导致 cc 在 -B 指定的路径中搜索其他工具(例如，汇编器)。因此，假设您在/usr/local/bin 中安装了不同版本的 binutils，如果您仅想使用该链接器(而不是 /usr/local/bin/as, et. al.)，你可以这样做:

mkdir /tmp/usemyld
ln -s /usr/local/bin/ld /tmp/usemyld
cc -B/tmp/usemyld foo.c -o foo

-B 有自己的一组规则，允许您覆盖 gcc 编译器尝试使用的不同文件(程序、库、包含文件、数据文件)。这至少可以追溯到 gcc 2.95 - 阅读 gcc 手册/信息页。我不知道 -B 的行为与 clang 的兼容性如何。如前所述，clang 手册页中目前没有记录。但它运行良好，让我可以选择如上所示的备用链接器。

gcc 还支持调用 -wrapper 指定的脚本/程序。 clang 没有(目前)。您也可以使用它并指向一个包装器脚本，该脚本会改变编译器正在调用的程序。我不知道 collect2 是否注意 -wrapper 选项(对于 gcc，collect2 是调用至少在编译 c/c++ 程序时链接器)。

[1] collect2 的 gcc 信息页中记录的链接器搜索顺序表示，如果配置了 GCC，它将首先搜索“硬编码链接器文件名”使用 '--with-ld' 选项”)。所以如果你的 gcc 没有配置 '--with-ld'，那么它最终会在 -B 指定的路径中搜索(如果它没有找到 real-ld第一)。如果您的 gcc 是配置了 --with-ld，则 -B 选项不会帮助您指定您选择的替代链接器。

关于c++ - 与 'cc' 链接时如何指定备用链接器命令，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40470931/