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

[Shankar Easwaran]

If its doing that, it might be following the Darwin model. The Darwin 
model picks up all the object files and puts all the libraries that it 
wants to link inside a Group(Snipped from a discussion earlier with Nick).

May be COFF should follow similiar things here.

Thanks

Shankar Easwaran

On 11/22/2013 4:09 PM, Rui Ueyama wrote:
> I'm not sure if it's usual that you specify the library files *after* the
> object files, because in the command line to link LLD on Windows, "lld.obj"
> is given as the last argument in the command line. It may be exceptional,
> but the link would succeed anyway, so it happened to demonstrate that the
> link order is not the same as in Unix.
>
> On Fri, Nov 22, 2013 at 9:16 AM, Mikael Lyngvig <mikael at lyngvig.org> wrote:
>
>> The way I recall DOS/Windows linking, you could specify object files after
>> the library files and the link would still succeed.  As a matter of fact,
>> you usually speciy the library files after the objects files on Windows.
>>   You might want to experiment with the Microsoft Linker to see how it does
>> things.  It has been almost twenty years since I did linkers, but I recall
>> that things were done in such a way that you never had to juggle load order
>> to satisfy the linker's resolution algorithm.  Sorry if I am a bit hazy on
>> this, but it has been too long since I developed linkers for me to remember
>> the precise details.
>>
>> -- Mikael
>>
>>
>>
>>
>> 2013/11/22 Shankar Easwaran <shankare at codeaurora.org>
>>
>>> On 11/20/2013 7:33 PM, Mikael Lyngvig 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.
>>>>
>>> Are you saying that windows linkers, just go over the input .obj files
>>> and then look at .lib files ?
>>>
>>>     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.
>>>>
>>> GNU has --allow-multiple-definitions, with which the first defined symbol
>>> wins, if they are defined in multiple object files.
>>>
>>>   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.
>>>>
>>>>   Unix link also does the layout as how symbols were resolved from the
>>> input files in command line order.
>>>
>>> This can be controlled in lld, where the LinkingContext chooses whats the
>>> next file to bring to the resolver to resolve symbols.
>>>
>>> Thanks
>>>
>>> Shankar easwaran
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>>> by the Linux Foundation
>>>
>>>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation