[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified

["davek at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447

--- Comment #9 from Dave Korn <davek at gcc dot gnu.org> 2011-04-07 22:22:51 UTC ---
(In reply to comment #8)
> > The correct fix is going to be in the linker, not the compiler, by implementing
> > a second library scan pass and obsoleting the pass-through mechanism.  I've got
> > a revised version of that experimental patch that I'll attach to this PR for
> > reference.
> 
> How does this affect circular dependencies between user supplied libraries. ld
> used to resolve these ok, and from the outside it seems like a similar problem.

It doesn't affect them at all.

This problem only arises because the LTRANS phase (when the plugin invokes
lto-wrapper to recompile all the IR files that it has claimed) sometimes
creates new undefined references that weren't in the LTO symbol tables in the
original IR.  However, it is guaranteed that these references are only ever
going to be to functions that the compiler knows about itself as builtins, so
will only ever result in references to the various compiler language runtimes
and the core system libraries; for user-supplied functions.

LTO creates symbol tables in the IR files that drive the linker's initial
symbol resolution process, and these symbol tables will contain explicit
references to any external functions that aren't part of the language and
compiler runtimes; it however deliberately omits references to compiler
builtins, since they may well be optimised out during LTRANS.

So, everything related to user-supplied functions should behave identically
regardless of LTO, either with or without this extra patch to cause GCC to
rescan the libraries.