[lld] r195289 - [PECOFF] Do not check if library is already added.

[Rui Ueyama]

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.

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?


On Wed, Nov 20, 2013 at 5:33 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote:

> 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.
>
> 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.
>
>
> -- Mikael
>
>
> 2013/11/21 Rui Ueyama <ruiu at google.com>
>
>> 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.
>>
>> Currently the LLD checks if a library specified with /defaultlib is
>> already
>> added to the input graph and do not add if it's already there. It causes
>> some undefined symbols remain unresolved.
>>
>> For example, oldnames.lib depends on kernel32.lib. What happens if
>> /defaultlib:kernel32.lib is given from the command line? The LLD reads
>> .drectve
>> section of oldnames.lib, finding that it contains
>> "/defaultlib:kernel32.lib".
>> However, the LLD won't add the kernel32.lib to the input file list
>> because it's
>> already added.
>>
>> The resolve order in the above case is kernel32.lib and oldnames.lib. So,
>> undefined symbols in oldnames.lib, which need to be resolved by
>> kernel32.lib,
>> remains undefined. It's a wrong behavior.
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131121/d9a22352/attachment.html>