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

[Mikael Lyngvig]

Hi Rui,

Sorry for the late answer, you mail accidentally made it into the thrash
can.

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.



2013/11/22 Rui Ueyama <ruiu at google.com>

> 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/20131126/3732e346/attachment.html>