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

[Mikael Lyngvig]

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/f292abde/attachment.html>