[Bug ld/26314] Linking LTO objects with conflicting symbol definitions from static and shared libraries fails

[amodra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26314

--- Comment #5 from Alan Modra <amodra at gmail dot com> ---
> https://gitlab.com/x86-gcc/gcc-bugs

Thanks for that.  Here are my observations about the link:
gcc -O2 -g -o ar -Wl,--as-needed arparse.o arlex.o ar.o not-ranlib.o arsup.o
rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o
libbfd-2.35-3.fc33.so libiberty.a -Wl,-R,.

All of the above .o files are lto, leading to libbfd-2.35-3.fc33.so not being
found needed when loading the IR objects.  That's problem number one:  We
exclude IR references when deciding a shared library is needed.  See PR15146. 
Thus none of the libbfd.so symbols are loaded before libiberty.a is scanned,
and libbfd.so contains copies of libiberty.a functions.  We ought to be using
the libbfd.so copies rather than extracting them from the archive (an object is
extracted even to satisfy IR symbols).  After lto recompilation, libbfd.so is
of course found to be needed and loaded.  But that causes more problems.  The
lto recompilation didn't see symbol references from libbfd.so and variables
like _xexit_cleanup are made local in the recompiled objects.  Oops, two copies
of them.  Finally, those silly undefined symbols in the lto output debug files,
combined with definitions in both libbfd.so and IR objects result in IR symbols
being made dynamic.

-- 
You are receiving this mail because:
You are on the CC list for the bug.