Re: About gcc builtin atomics

[Thorsten Glaser <tg@mirbsd.de>]

Mikael Pettersson dixit:

>Check the input object files in the above link step to see which one
>brings in the reference to __sync_sub_and_fetch_4.  My suspicion is
>that it's nouveau_dri.so.tmp, libdrm_nouveau.so, or libdrm.so; if so,
>then that .so file must be rebuilt against the new libgcc_s.so linker
>script.

I had a similar idea, especially as I couldn’t reproduce the issue
with a stand-alone .cc shlib, but when trying to make a test programme,
I froze my VM, so I’ve had to nuke the chroot now. Building a gcc
with your patch suggestion atm.

>.so files can include code from libgcc.a just fine, but every such
>.so file must be produced by linking it explicitly against both the
>shared and the static libgcc.

Ah okay.

>The occurrence in libstdc++.so is a private definition: it's used
>for libstdc++.so's own references but cannot be used by other .so
>files

Yes, I guessed so, but -Wl,-t showed it already pulled the one
from libgcc.a in during _that_ link, so it must’ve been one of
the other .so files (none of which had an U on __sync_*, though).
Hmpf. I wish all DLLs would be linked with no-undefs…

Thanks again,
//mirabilos
-- 
[00:02] <Vutral> gecko: benutzt du emacs ?
[00:03] <gecko> nö          [00:03] <gecko> nur n normalen mac
[00:04] <Vutral> argl       [00:04] <Vutral> ne den editor
	-- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)