Hi, On 1/17/25 17:45, Alexandre Rossi wrote:
Some upstreams have gone through build system tests to assess whether to build with libatomic or not. Adding -latomic is simpler. I wonder if the build system configure stage test is overkill.
Yes and no. A lot of the tests are just broken, like "compile and link a program incrementing an atomic integer, try with no extra libraries and with libatomic" -- in principle you'd need to repeat this with all data types used, then you'd get a reliable result.
It's similar to how libm is used -- if you use fsin(), this may be a single assembler instruction, or a call to a function that is IEEE754 conformant and sets errno, and that implementation detail determines whether you want to link against libm or not, but if you test whether fsin() requires -lm, that doesn't tell you whether fabs() requires -lm.
Likewise, 4-byte atomics being inlined doesn't tell you if 1-byte or 16-byte atomics are also inlined, or whether there is special handling for signed or unsigned integers.
Within Debian, always linking with --as-needed is a simple fix, but it depends on using a linker that understands --as-needed, so it's not portable enough to be submitted upstream.
In my own packages, I check if libatomic exists, and if it does, I unconditionally link if I use any atomics. I also check if the linker accepts --push-flags, if it does I generate a -Wl,--push-flags,--as-needed,-latomic,--pop-flags sequence, if not, the unconditional link will generate dpkg-shlibdeps warnings about unnecessary linking on amd64, but that's better than failing on other platforms.
Simon
