Clang toolchain type should not be bound with LLD

[Magnus Ihse Bursie]

On 2025-01-22 16:16, Bingwu Zhang wrote:

> Hi!
>
> I have signed the individual OCA agreement but it has been still showing
> "Under Review" for 24 hours. I will make a PR as soon as it is reviewed.
>
> I think it will not require too much work to support other linker
> combinations, almost no extra work.

On the contrary, that can be very tricky. The problem is that we pass 
linker options using -Wl,... to the compiler, and thus we need to know 
what arguments the linker understands. For non-linux development, there 
is a 1-to-1 relationship between compiler and linker, so there is no 
question what the linker accepts.

Since clang toolchains almost exclusively use lld, we decided to make it 
compulsory. Similarly, lld is not supported when building with gcc.

The problem here is not setting different -fuse-ld flags; it is knowing 
what other arguments the linker accept.

/Magnus

> On most Linux distributions, Clang uses
> the BFD linker by default, rather than LLD. If a compiler/linker combination
> is not working, we could try to address the problem on the linker or compiler
> upstream side.
>
> On Wednesday, January 22, 2025 11:06:04 PM GMT+8 Erik Joelsson wrote:
>> Hello,
>>
>> I would say that we aren't against taking in variables on the configure
>> command line for setting executables to use in the build, as that's a
>> well established standard way of doing just that with Autoconf. The
>> built in Autoconf macros for CC and similar executables pick up such
>> variables, so at least in principle I'm not against the idea of being
>> able to do so for the linker. I may have opinions, and I'm sure Magnus
>> would have too, on the particulars of how this is implemented.
>> Unfortunately, I can't comment on this particular implementation
>> proposal until it's submitted in a PR with the OCA signed.
>>
>> /Erik
>>
>> On 1/22/25 3:19 AM, Julian Waters wrote:
>>> Hi!
>>>
>>> I believe it's not a hard requirement that special variables can't be
>>> used, just that it's strongly discouraged in favour of configure
>>> options. I'm not sure if we support linker combinations other than the
>>> one the compiler comes with, the extent of my knowledge is that I
>>> think Oracle uses gold for gcc, but regardless you'd have to ask
>>> Magnus for that. But the issue is still that different linkers might
>>> need to be treated differently by the build system, and it might not
>>> yet be prepared to use linkers like mold instead of lld
>>>
>>> best regards,
>>> Julian
>>>
>>> On Wed, Jan 22, 2025 at 5:54 PM Bingwu Zhang <xtex at envs.net> wrote:
>>>      Hi!
>>>      
>>>      The patch I mentioned in last message will first try to resolve
>>>      the full,
>>>      absolute path of lld, and use --ld-path to pass the path to Clang.
>>>      It should
>>>      have the same effect as passing -fuse-ld=lld. If it failed to do
>>>      so, it will
>>>      fallback to use -fuse-ld=lld to let Clang pick up the proper linker.
>>>      
>>>      btw it seems that CC and CXX is picked by the build system [1].
>>>      Why don't we
>>>      just pick up the variable?
>>>      
>>>      I will later change it to use a configure option. How about
>>>      --with-linker-path?
>>>      
>>>      Thanks! :)
>>>      
>>>      [1] https://github.com/magicus/jdk/blob/
>>>      a62a870150cf199f16277b478af2f5d937255b3c/make/autoconf/toolchain.m4#L4
>>>      30
>