[llvm-dev] Please dogfood LLD

Andrew Kelley via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 21 10:26:58 PDT 2017


On Sat, Mar 18, 2017 at 9:06 PM, Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> It looks like "stockfish" and "TTSIOD" also failed to link as well.
> Stockfish seems to fail because by default when compiling with GCC the
> makefile uses -flto and LLD doesn't understand the GCC IR files. I think
> the COFF linker handles this by shelling out to the system linker in the
> case of MSVC LTO, and ELF should probably do the same.
> I haven't looked into TTSIOD.
>

I suggest that the correct behavior in the case of encountering foreign LTO
files is to print an error message such as "Encountered foreign LTO files.
When using LLVM LLD with LTO, object files must be in the LLVM bitcode
format, usually produced by clang. To solve this choose an option: 1. Use
clang to produce the object files 2. Use a linker compatible with the
object files (probably the system linker) 3. Disable LTO."

Ultimately I think that printing an error message such as this and exiting
would result in less user confusion than shelling out to the system linker.
If the phoronix person doing this test had seen this, they might have tried
to follow one of those 3 steps instead of concluding that LLD was broken.

If we do end up going with the shelling out approach, I as an upstream user
would appreciate if there was a flag to disable this feature, and make it
an error if it had to shell out. I am using LLD to intentionally not depend
on the system linker, and if LLD shells out to the system linker then it
thwarts this goal.

Also, this shelling out approach only works on the native platform and not
for cross compiling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170321/a32be45b/attachment.html>


More information about the llvm-dev mailing list