为什么编译器不通过编程方式调用链接器？跨链接及系统链接器相关问题

为什么Clang不将lld作为库集成调用 #

• 模块化设计需求：LLVM生态的核心设计逻辑就是组件解耦可替换，Clang作为前端，允许用户自由选择ld、gold、lld、MSVC link.exe等任意符合要求的链接器，强制集成lld会破坏这种灵活性，也不利于发行版、厂商按需定制工具链。
• 稳定性隔离：链接过程涉及大量低层级的二进制解析、内存操作，若输入存在损坏的目标文件、非法参数，很容易触发崩溃。使用独立进程调用链接器时，链接异常只会终止链接进程，不会影响Clang前端主进程，也更便于问题定位。
• 平台兼容性考量：部分专有平台的链接器存在专属扩展逻辑，比如macOS的ld64、部分嵌入式平台的定制链接器，Clang作为通用前端无需绑定lld导致适配成本上升。
• 实际上当前Clang已经支持开箱即用lld，只需传入-fuse-ld=lld参数即可调用，大多数发行版也会将lld作为Clang的可选配套组件分发，已经实现了不依赖系统默认链接器的能力，只是没有采用库集成的形式。

链接器是否支持跨平台生成二进制 #

不是所有链接器都支持跨链接：

• 开源跨平台链接器（比如lld、GNU ld）只要编译时开启了对应目标架构、文件格式的支持，就可以实现跨平台生成，比如在Windows系统上用lld链接ELF格式的目标文件，输出Linux平台可执行程序。
• 专有平台默认链接器（比如Windows自带的link.exe、macOS自带的ld64）通常不支持跨目标生成，只能输出对应平台的二进制文件。
  注：跨链接仅靠链接器支持不够，还需要准备目标平台对应的启动文件、标准库等依赖才能生成可用的二进制。

如何在程序中探测系统链接器路径 #

不需要硬编码路径的常用方案：

• 优先读取环境变量约定，大多数编译工具链都会遵循LD、LDFLAGS等环境变量的配置，优先使用用户指定的链接器路径。
• 类Unix平台可以调用which ld、Windows平台调用where link.exe搜索系统PATH环境变量下的链接器可执行文件，获取路径。
• 基于LLVM开发的话可以直接调用LLVM内置的ToolChain相关接口，LLVM已经实现了全平台的链接器探测逻辑，无需自行实现。
• 可以做多层级 fallback：先查用户指定路径、再查LLVM配套的lld路径、再搜索PATH、最后检查常见系统默认路径，覆盖绝大多数场景。

内容的提问来源于stack exchange，提问作者rahul valluri