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

[Rui Ueyama]

On Fri, Nov 22, 2013 at 2:14 PM, Shankar Easwaran
<shankare at codeaurora.org>wrote:

> 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).
>

Which thread?


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131122/bacf81eb/attachment.html>