Faster linker

[Atila Neves]

On Friday, 9 November 2018 at 15:30:24 UTC, Joakim wrote:
> On Friday, 9 November 2018 at 15:08:19 UTC, Atila Neves wrote:
>> On Friday, 9 November 2018 at 13:28:42 UTC, Joakim wrote:
>>> On Friday, 9 November 2018 at 12:19:43 UTC, Atila Neves wrote:
>>>> On Friday, 9 November 2018 at 03:47:09 UTC, Joakim wrote:
>>>>> On Friday, 9 November 2018 at 02:47:38 UTC, bennygui wrote:
>>>>>> [...]
>>>>>
>>>>> Yes, LDC has the -linker=gold flag, that you can use to 
>>>>> pass a different linker to your C compiler. Try it with 
>>>>> lld, it's the fastest of all the linkers.
>>>>
>>>> lld mostly produces crashing binaries for me on Linux.
>>>
>>> I find that hard to believe, considering Android is switching 
>>> to it:
>>
>> To the extent of my knowledge, Android doesn't link D 
>> binaries. It may well work for C and C++.
>
> OK, your statement made no reference to D, so I thought you 
> were talking generally.
>
>> I tried symlinking /usr/bin/ld to /usr/bin/ld.lld, and... it 
>> seems to work now. The last time I tried (6 to 12 months ago? 
>> I don't remember) it produced crashing binaries most of the 
>> time for D code.
>>
>> I guess I should switch for good now then!
>
> Maybe you were using an old or buggy version of lld back then. 
> I've just been trying lld for Android and I was stunned at how 
> fast it ran, as I've been stuck with bfd for Android for some 
> time now. After making some druntime tweaks so I can use any 
> linker on Android, I got the exact same test results when 
> running the dmd testsuite natively on Android/AArch64 with bfd, 
> gold, and lld.

Older, yes. Old, no (I'm on Arch, nothing is old). I was also 
stunned by how fast it ran. Then I was more stunned by how crashy 
the resulting binaries were.

>> Only in the unreleased 1.13.0 version, and using it in the beta
>
> No, it was added with 1.3.0, more than a year ago:
>
> https://github.com/ldc-developers/ldc/releases/tag/v1.3.0

Huh, I could've sworn I tried it with 1.12.0 and it didn't work, 
but I tried again and it recognises the flag. My bad.

>> % ldc2 -link-internally -L-L/usr/lib foo.d
>> lld: error: unknown argument: --no-warn-search-mismatch
>>
>> Not ready for production, then.
>
> No, the issue is that ldc pre-configuring it for every 
> toolchain and distro would be a giant PITA:
>
> https://github.com/ldc-developers/ldc/issues/2717

I sympathise with the difficulty, but as I user I don't care - it 
doesn't work.

> The way dmd and ldc work now is that they expect there to be a 
> C compiler installed, and simply invoke the local C compiler to 
> link everything properly, assuming rightly that it will pass 
> all the right flags and libc object files to its linker.
>
> `-link-internally` cannot possibly do that- we'd have to 
> maintain a database of all possible toolchain configurations 
> out there- so it depends on _you_ configuring it for your 
> environment if you want to use it. Once you do, it's just a 
> built-in lld, it should work just as lld does.

Or I could symlink /usr/bin/ld to /usr/bin/ld.lld and not have to 
worry about any of that. Except for letting me switch linker per 
project, `-link-internally` is useless to me.

There's also the `--no-warn-search-mismatch` problem.