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