https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #33 from Kewen Lin <linkw at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #27) > On Fri, 2 Aug 2019, linkw at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287 > > > > Kewen Lin <linkw at gcc dot gnu.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > CC| |linkw at gcc dot gnu.org > > > > --- Comment #26 from Kewen Lin <linkw at gcc dot gnu.org> --- > > > The odd thing is that if you omit libfoo1.so then it will consider > > > libfoo.a later but not when it can resolve from libfoo1.so. > > > > > > That's a bit inconsistent but arguably the bug is with GCCs > > > symbol table creation of the LTO IR. > > > > Do we have option to dump the actual final linking command to link all > > ltrans > > objects? I can only see the command to generate ltrans object with as. Is it > > possible a library order issue in final linking? > > The ld invocation for the final link is the same as the one spawning the > LTO WPA and LTRANS phases - the LTO plugin feeds back extra objects > for the re-link done by the very same ld process. > > Not sure if ld prints anything like an "effective final link command" > when adding verbosity (try -Wl,-v -Wl,-debug etc.). > > So - there isn't something like a "final linking command" and the final > linking approach also differs from BFD and gold for example. Thanks Richard! My local repo is old and doesn't pick up commit r271202 which respects save-temps to save output objects after LTRANS. The linking process with plugin is quite different from my stale knowledge on general lto linking, as you mentioned the objects out from LTRANS are fed back into the linking process by using plugin/ld interface. This issue seems use-linker-plugin only, I disabled it by -fno-use-linker-plugin and got the expected result, but it will miss all befenits from tight integration with ld. It's bad and just a workaround try. Another workaround with -Wl,--whole-archive -lmass -Wl,--no-whole-archive is also not practical due to code bloat and possible cache impact etc.
