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.