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

[Shankar Easwaran]

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