[Bug ld/26806] Suspected linker bug with LTO

[amodra at gmail dot com]

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

--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
(In reply to Nick Clifton from comment #2)
> I am hoping that Alan will review the patch, but just FYI it is working for
> me in rawhide.
There is an email thread on that subject.  I committed a couple of patches, 
a896df97b95 and 1e3b96fd6cf that changed --as-needed behaviour, because I
fairly strongly believed we can't get all the corner cases correct in the
linker.  I continue to think that too.  We need to inform LTO of shared library
symbols before recompilation, but with --as-needed those symbols might not
actually be available in the final executable.  They are of course if the
recompiled object references something to make the as-needed library needed. 
But what if LTO makes decisions based on a set of symbols that is different to
that in the final executable, due to an as-needed library being dropped?  Can
you say with any certainty that this will never happen?

Those two patches of mine make
https://sourceware.org/pipermail/binutils/2020-September/113227.html
superfluous.  I didn't forsee we would have anything like the redhat bugzilla. 
:-(

Note that the comment in the log for a896df97b95 about duplicated copies of
variables isn't completely correct.  A duplicate being present doesn't
necessarily cause a problem: the duplicates need to be used to actually cause a
problem.  That probably wan't happening in the libbfd.so case, but Jeff Law
posted about a case where duplicates did occur *and* were used. 
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555899.html

So this whole thing is a bit of a mess.  Reverting my patches and applying HJ's
might work as a quick solution, but do please check out Jeff's testcase.

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