[llvm-dev] Please dogfood LLD

Sean Silva via llvm-dev llvm-dev at lists.llvm.org
Tue Mar 21 12:55:02 PDT 2017


On Tuesday, March 21, 2017, Andrew Kelley <superjoe30 at gmail.com> wrote:

> On Sat, Mar 18, 2017 at 9:06 PM, Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org
> <javascript:_e(%7B%7D,'cvml','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.
>

Yeah. I think for LLD/COFF shelling out to the system linker is an opt-in.

-- Sean Silva


>
> 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/8021d27e/attachment.html>


More information about the llvm-dev mailing list