Page MenuHomeSolus

Enable support for llvm's LLD linker
AbandonedPublic

Authored by joebonrichie on Dec 11 2017, 12:39 AM.
Tags
None
Referenced Files
F10997393: D1605.diff
Thu, Jul 27, 7:18 AM
F10988740: D1605.diff
Mon, Jul 24, 12:24 PM
F10874700: D1605.id3935.diff
Jun 20 2023, 1:35 AM
F10853527: D1605.id.diff
Jun 13 2023, 10:52 AM
F10833717: D1605.diff
Jun 7 2023, 1:21 AM
F10764482: D1605.id3935.diff
May 19 2023, 7:25 AM
F10764338: D1605.diff
May 19 2023, 6:32 AM
F10753784: D1605.id3935.diff
May 16 2023, 6:56 PM

Details

Reviewers
None
Group Reviewers
Triage Team
Summary

Drop-in, very-speedy replacement for other linkers such as ld and ld.gold.

Signed-off-by: Joey Riches <josephriches@gmail.com>

Test Plan

Built against chromium 63 stable, which now requires LLD by default.

Diff Detail

Repository
R1972 llvm
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

So this ends up in llvm-clang right? Have to be careful that it doesn't turn up in normal builds as stuff shits itself when ld.gold is present. But I do want to test this as the default clang linker

Yeah it does, only reason ld.gold and lld don't work out of the box AFAIK is our use of --copy-dt-needed-entries whilst other distros use --no-copy-dt-needed-entries, generally packages will use the system default linker unless they are explicitly looking another linker such as ld.gold e.g. webkit2, also AFAIK. Still would like to test this against other packages that are built with clang I think lld is still too new for packages to look for it explicitly.

ikey added a subscriber: ikey.

Rebased it for ya