avoiding undesirable undef[weak] syms after relocatable linking

[Alexandre Oliva]

Hello, H.J.,

On Apr 13, 2024, "H.J. Lu" <hjl.tools@gmail.com> wrote:

>> $ gas/as-new t.s -o t.o && binutils/ar cr t.a t.o && binutils/ranlib
>> t.a && gas/as-new m.s -o m.o && ld/ld-new m.o t.a -o m -r &&
>> binutils/nm-new m | grep bar
>> w bar
>> $ ld/ld-new --version
>> GNU ld (GNU Binutils) 2.42.50.20240413
>> [...]
>> $ git log
>> commit 4ad25f3bed6bc4c010962b11fde1c70ce8c22cae
>> [...]

> Please open a bug report.

Can do (and thanks for the patch), but...  Are you positive that that's
a bug to begin with?

I am concerned that changing it might break something, though I can't
quite put my finger on what it is that might break with this change.

Say, given another object file, say x.o, to be final-linked with the
result of the relocatable link that this patch would change, couldn't a
symbol that resolved to the undefweak become a final link failure after
the change?  Or if the relocatable link output was made part of a
dynamic library, couldn't something break in case the undefweak symbol
was meant to be dynamically exported, but would now be entirely gone?

That's why I was thinking of controlling this behavior change with an
option.

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive