Hi Simon, Quoting Simon Richter (2025-01-16 16:52:19) > atomic operations require linking against libatomic — always have. Some > architectures inline a few functions, which is how you get away with omitting > the library on amd64 most of the time, but this is incorrect. > > No architecture specific patch should be required here, adding libatomic > everywhere is fine, possibly via > -Wl,--push-options,--as-needed,-latomic,--pop-options > > (although as-needed is likely default anyway)
I find this very interesting. I am fighting -latomic linking issues for quite a while now and what you just said makes me think that I am in severe lack of understanding here. Can you elaborate? My specific situation is: src:vcmi FTBFS on armel unless I apply this patch: https://sources.debian.org/src/vcmi/1.5.7%2Bdfsg-1/debian/patches/fix-armel-atomics.patch/ After more research together with vcmi upstream involvement I found out that linking vcmi against atomic is *only* required because it uses tbb::parallel_for from oneTBB: https://github.com/uxlfoundation/oneTBB/issues/1454 And then others have linked me to this GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 So I'm at a loss at deciding who is at fault and who should be fixing something. You say this should work out-of-the-box on amd64 mostly but everything I have come across handling std::atomic types builds fine on all architectures -- except armel. So which is the thing that gets things wrong here? - armel? - g++? - cmake? - oneTBB? - vcmi? Who should be patched? Relevant Debian bugs are #1089991 and #1088922 I'd very much welcome to be enlightened by you or anybody else on this list. :) Thanks! cheers, josch
signature.asc
Description: signature
