avoiding undesirable undef[weak] syms after relocatable linking
Alexandre Oliva
oliva@adacore.com
Sat Apr 13 10:15:16 GMT 2024
Hello, Nick,
On Apr 12, 2024, Nick Clifton <nickc@redhat.com> wrote:
> Hi Alex,
>> And here's how to trigger the problem:
>> as t.s -o t.o && ar cr t.a t.o && ranlib t.a && as m.s -o m.o &&
>> ld m.o -o m -r && nm m | grep bar
>> w bar
> Which version of the binutils are you using ? And for which target ?
Originally, 2.42 snapshots on multiple vxworks targets, but I'd tried on
x86_64-linux-gnu as well. Unfortunately, I see now that I made a
mistake in the command posted by email: somehow I dropped t.a from the
link command, presumably while editing it to remove local artifacts.
Please accept my apologies. Here's the correct command, now (not)
adjusted, so that it runs from the top of a binutils build tree. The
(unmodified) [tm].s files are attached.
$ 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
[...]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.s
Type: text/x-assembly
Size: 213 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20240413/359abc03/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m.s
Type: text/x-assembly
Size: 150 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20240413/359abc03/attachment-0001.bin>
-------------- next part --------------
--
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
More information about the Binutils
mailing list