[PATCH] D124999: ld.lld: Respect -fallback-gnu-driver.

Fri May 6 04:08:39 PDT 2022

shlevy added a comment.

In D124999#3496021 <https://reviews.llvm.org/D124999#3496021>, @mstorsjo wrote:

> In D124999#3496013 <https://reviews.llvm.org/D124999#3496013>, @shlevy wrote:
>
>> In D124999#3495825 <https://reviews.llvm.org/D124999#3495825>, @MaskRay wrote:
>>
>>> The description does not have information to justify why such an option is needed.
>>
>> We can split up the justification into two parts:
>>
>> 1. Why enable changing the default driver at all? D87418 <https://reviews.llvm.org/D87418>, introducing `LLD_DEFAULT_LD_LLD_IS_MINGW`, gives the primary justification: there are build systems which grep through `--help` for certain flags. E.g. any package using libtool <https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4#n5132> (so far I've hit this with `gmp` and `libffi` but there are certainly countless others) will think `lld` can't produce shared libraries. As a secondary consideration, if I'm manually invoking e.g. `x86_64-w64-mingw32-ld --help` I want to see the usage for the actual command I care about. As a tertiary consideration, if no machine type is set (with `-m`) then both the `ELF` driver and the `COFF` driver (which the `MinGW` driver uses under the hood) have logic to detect the appropriate machine type from input files, but without the ability to change the default driver there is no way to take advantage of that autodetection via `ld.lld` for COFF.
>> 2. Why make this knob configurable at run-time? As @Ericson2314 touches on in https://github.com/ClangBuiltLinux/llvm-distributors-conf-2021/issues/20, the LLVM toolchain has a great (and IME unique amongst serious compilers) virtue of target-agnosticism in the build process. This has design benefits, but the immediate cash value is that if I fix `build` and `host` I can build one core toolchain and use the same underlying binaries to compile for all of the targets that LLVM supports. Without run-time configuration, to achieve the benefits of point 1 we would have to break this invariant and build a different `lld` for `MinGW` targets than for non-`MinGW` targets. With this (or an analogue that uses env vars, if that's preferred), we can instead simply ensure that the build environment for the specific target passes the right flags (as I do here <https://github.com/NixOS/nixpkgs/blob/b8182b9d00b921d8c5d4b5501139f5ba63ffd29d/pkgs/build-support/bintools-wrapper/add-lld-ldflags-before.sh>).
>
> I guess the main question is that if you configure the default by passing an option (as opposed to an environment variable), why isn't it possible to achieve the same by just passing e.g. `-m i386pep`? I guess that's somewhat answered by 1. above - doing that loses the chance of letting the linker autodetect things, for the cases where that could be done.
>
> In practice though, I haven't yet used lld in a mingw context where the intended target architecture wasn't known at that point. I'm not familiar with NixOS, but for the cases where you'd want to set this default to make lld default to mingw behaviour, wouldn't you also know the intended architecture at the same time?

I just saw your wrapper-script in `llvm-mingw` now. If the machine type is truly fixed once you fix the target triple prefix, then this is probably fine for my use case.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124999/new/

https://reviews.llvm.org/D124999