<br><br>On Tuesday, March 21, 2017, Andrew Kelley <<a href="mailto:superjoe30@gmail.com">superjoe30@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 18, 2017 at 9:06 PM, Sean Silva via llvm-dev <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','llvm-dev@lists.llvm.org');" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div>I haven't looked into TTSIOD.</div></div></div></div></blockquote><div><br></div><div>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."</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>Yeah. I think for LLD/COFF shelling out to the system linker is an opt-in.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Also, this shelling out approach only works on the native platform and not for cross compiling.</div></div></div></div>
</blockquote>