<div dir="ltr">Hi Rui,<div><br></div><div>Sorry for the late answer, you mail accidentally made it into the thrash can.</div><div><br></div><div>The linker would issue an error or a warning but continue the link as if nothing had happened.  This is important if you want to override a set of library symbols like malloc and free without having access to the source code.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/22 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">Thank you Mikael for the very valuable comment. I did not understand the exact semantics of Windows-style link resolve order. We should definitely consider to use that method in the LLD, although I have no concrete idea to do that at this moment. Currently the LLD supports only Unix-style symbol resolve order.<br>


<div><br></div><div>One question is that you said that you can override a library symbol by giving a file containing the same symbol before the library. Doesn't it cause the linker to fail with duplicate symbol error?</div>


</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 20, 2013 at 5:33 PM, Mikael Lyngvig <span dir="ltr"><<a href="mailto:mikael@lyngvig.org" target="_blank">mikael@lyngvig.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div><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></div></div><div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">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></div></blockquote></div><br></div>
</blockquote></div><br></div>
</blockquote></div><br></div>