Having to append -latomic for successful linking is becoming somewhat common (especially for riscv), but its validity depends on whether built-in atomics already exist for the platform (e.g. originally highlighted in bug 820095, clang on arm doesn't need this and will bail out). Perhaps we should have an append-atomic-flags a la append-lfs-flags to make life easier, which would avoid the need for something like: ``` if use arm || use ppc ; then append-flags $(test-flags-CCLD -latomic) fi ``` ... given that this isn't completely accurate anyway (e.g. arm doesn't always need it, and we're missing some arches like riscv there).
Can't say I've seen an issue like this on MIPS. Is this something specific to clang/LLVM, or has it happened on gcc as well?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=29cf769f4de6550851e74829c2011c2e23554cc7 commit 29cf769f4de6550851e74829c2011c2e23554cc7 Author: matoro <matoro@users.noreply.github.com> AuthorDate: 2022-07-10 22:41:17 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-20 23:35:14 +0000 flag-o-matic.eclass: implement append-atomic-flags My take on implementing bug 820101 as conservatively as possible. This will append -latomic only when absolutely necessary (even though it's probably not required to be that conservative due to our use of --as-needed). This will take flags into account when testing as well. For example, if you compile with -march=i386, this would require linking libatomic even if the same toolchain with a higher -march level would not require it. So rebuilding the same package with the same flags may change whether -latomic is linked at build time if the CFLAGS change. Another instance might be switching from GCC to clang - the former requires explicitly linking -latomic, while the latter does not even HAVE libatomic (see bug 820095) as all atomic intrinsics are built-in internally. This function would safely detect this and not append -latomic. There is an optional parameter [bytes]. You can use this if you want to be specific about what size atomic support is required. For example, there are several platforms like MIPS where the 32-bit version has 1-, 2-, and 4-byte atomics builtin but requires libatomic linkage for 8-byte atomics. If your program only requires, say, 4-byte atomics, you can use append-atomic-flags 4 and this will then not attempt to link libatomic on 32-bit MIPS. I tested using this to solve bug 688574 on 32-bit SPARC. Bug: https://bugs.gentoo.org/688574 Bug: https://bugs.gentoo.org/820095 Closes: https://bugs.gentoo.org/820101 Closes: https://github.com/gentoo/gentoo/pull/26334 Signed-off-by: Sam James <sam@gentoo.org> eclass/flag-o-matic.eclass | 145 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec90f4c3a4e0ef9841dede7b18df90e2aceafd45 commit ec90f4c3a4e0ef9841dede7b18df90e2aceafd45 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-03-28 03:47:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-29 18:45:05 +0000 flag-o-matic.eclass: simplify implementation and work in all cases It curently uses some magic test to decide whether handcrafted code works with or without -latomic. But it can claim that -latomic is not needed for that case, while it is still needed for other cases. > okay so append-atomic-flags does not work for me in this case > noise-suppression-for-voice is doing `struct RnNoiseStats { uint32_t a, b, c, d; }; std::atomic<RnNoiseStats> m_stats;` > not just a single large integer It is simplest to always add -latomic when an ebuild gets that deep feeling that yeah, it would like some atomics please. The downsides to listing a linker library are exactly: - it might be unavailable - it might be unneeded And the former case is trivial to solve -- this function already does so -- while the latter case has a sanctioned approach that is already used for other intrinsic compiler libraries, but not for atomic "because the build system would have a hard time if we had to build atomic early on" which isn't a very good reason to break ebuilds which aren't building sys-devel/gcc. As a side benefit, we now handle -latomic such that a package which requires it, but only for parts of the installed package, does not overlink to libatomic in *all* binaries/libraries, even if the default LDFLAGS are overridden and the global -Wl,--as-needed disappears. Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 Bug: https://bugs.gentoo.org/820101 Bug: https://bugs.gentoo.org/925672 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> eclass/flag-o-matic.eclass | 80 +++++++++++----------------------------------- 1 file changed, 19 insertions(+), 61 deletions(-)
