Faster linker

Joakim dlang at joakim.fea.st
Fri Nov 9 15:30:24 UTC 2018


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.

>> "LLD is now available for testing. AOSP is in the process of 
>> switching to using LLD by default and the NDK will follow 
>> (timeline unknown). Test LLD in your app by passing 
>> -fuse-ld=lld when linking."
>> https://github.com/android-ndk/ndk/wiki/Changelog-r18
>>
>> It may still have bugs though, maybe you can report your 
>> problems.
>>
>> LDC comes with lld built in, available through the 
>> `-link-internally` flag that kinke added.
>
> 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

> yields this:
>
> % ldc2 -link-internally foo.d
> lld: error: unknown argument: --no-warn-search-mismatch
> lld: error: unable to find library -lrt
> lld: error: unable to find library -ldl
> lld: error: unable to find library -lpthread
> lld: error: unable to find library -lm
>
> Ok, let's look in /usr/lib explicitly then (which shouldn't be 
> needed):
>
> % 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

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.

I plan on moving the native packages for the Termux app on 
Android to use -link-internally by default (they currently 
default to clang/bfd), since it should be straightforward to add 
the necessary linker flags and logic for that limited 
environment. Maybe we could do that for Mac and even Windows 
someday too, but I can't imagine we'll ever have an official ldc 
that works for every linux distro! ;)


More information about the Digitalmars-d mailing list