At Sat, 22 Feb 2025 06:28:16 -0000 (UTC), mlelstv%serpens.de@localhost (Michael van Elst) wrote:
Subject: Re: "common" symbols are no longer common?!?!?!
>
> gcc switched the default to -fno-common with gcc10.
Ah ha! Indeed not too long after posting I found the following:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
I'm pretty sure that's what I remember reading about this issue too.
> Generally, this is a good thing. There are very few programs
> that use common variables
I agree on both counts! (at least I hope the latter is true!)
In this case of course it is two separate objects in two different
libraries both trying to define the same global variables. But it's a
little more complicated than just that it seems.
> and accidentially merged symbols
> are now a linker error.
Well, but that's not exactly always happening is it?
Clearly I would never have encountered this problem if the linker did
always throw an error. It would have been fixed at, or very shortly
after, the time gcc was upgraded or else the build would have been and
remained broken.
Unfortunately this is another failure of the lax nature of the
link-loader, i.e. ld(1), when run with "-Bdynamic" (or without
"-Bstatic") and the very bad behaviour of the runtime linker for
situations like this.
I'm not quite sure how this code could have got into this mess in the
first place, but clearly dynamic linking causes the problem to be hidden
entirely. I would I guess the author didn't expect or need "common"
linking here (I'm not sure that's what ld.so is doing in this case).
In theory this shouldn't even happen in this case. These symbols are
clashing because librumpnet(net_stub.o) is being pulled in while
librumpnet_net(if.o) is also being pulled in. The latter library must
be missing some symbol that is supplied in net_stub.o. Generating a
linker map suggests the key symbol is rumpns_bridge_output, but that may
not be all:
/Users/woods/build/woods/very.local/trunk-amd64-destdir/usr/lib/librumpnet.a(net_stub.o)
/Users/woods/build/woods/very.local/trunk-amd64-destdir/usr/lib/librumpnet_net.a(if_ethersubr.o) (rumpns_bridge_output)
librumpnet_bridge(if_bridge.o) has a rumpns_bridge_output symbol in it,
but including it in the link command before librumpnet_net doesn't
change anything because nothing earlier wants to pull in if_bridge.o
beforehand.
I'm grasping at straws here though. The rump implementation may as well
be black magic as far as I can understand it!
Too many twisty independent libraries and hacks like net_stub!
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpBRKoC5rc5b.pgp
Description: OpenPGP Digital Signature