<div dir="ltr">As a former DOS/NT linker engineer (SSI, XLINK386, an absolute embedded linker - probably the world's most advanced linker ever), I'd like to add that Windows linkers don't search in the Unix-style one way only.  On Windows, you can do things like foo.obj kernel32.lib oldnames.lib without running into problems.  On Windows, the linkers typically make a gigantic symbol table of all the symbols defined in the input files and then resolve that way.  The only time the link order matters is if there are duplicate symbols, in which case the first input file that provides the symbol is picked so that the user can predict what happens if he or she overrides a library symbol.<div>
<br></div><div>I think you should consider to use that method in lld as the Unix method is less than optimal: It is not a rare sight that a Unix link fails only because of wrong library order.  Then you have to sit and juggle the linker's input files for a while, until the beast caves in and does what you expect it to do: Link with the least amount of trouble on your parth.</div>
<div><br></div><div><br></div><div>-- Mikael</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/21 Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>For some reason, the reason of this change was omitted from the commit message. Here's the description I meant to include in the commit log. Pasting it for the record.</div>
<div><br></div></div>

<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>Currently the LLD checks if a library specified with /defaultlib is already</div></div><div><div>added to the input graph and do not add if it's already there. It causes</div>


</div><div><div>some undefined symbols remain unresolved.</div></div><div><div><br></div></div><div><div>For example, oldnames.lib depends on kernel32.lib. What happens if</div></div><div><div>/defaultlib:kernel32.lib is given from the command line? The LLD reads .drectve</div>


</div><div><div>section of oldnames.lib, finding that it contains "/defaultlib:kernel32.lib".</div></div><div><div>However, the LLD won't add the kernel32.lib to the input file list because it's</div></div>


<div><div>already added.</div></div><div><div><br></div></div><div><div>The resolve order in the above case is kernel32.lib and oldnames.lib. So,</div></div><div><div>undefined symbols in oldnames.lib, which need to be resolved by kernel32.lib,</div>


</div><div><div>remains undefined. It's a wrong behavior.</div></div></blockquote><div><br></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>