On 2025-01-16 at 20:16 +0100, Johannes Schauer Marin Rodrigues wrote: > 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?
Hi Josch, It's not that complex.¹ If you use an atomic, you should also be linking with atomic (i.e. -latomic). This is similar to using -pthreads if you are using multiple threads, or -lresolv if you use gethostbyname() What makes things complicated here is that in most architectures, gcc is able to inline everything, and libatomic is not really needed, so you don't need to add -latomic and it just works. ...until it doesn't, such as in armel. Just like you can use gethostbyname() directly, since this is provided by libc, which is implicitly linked by default. But you would need to specify -lresolv in Solaris, or it won't link. So the solution would be just to add -latomic Saying instead -Wl,--push-options,--as-needed,-latomic,--pop-options is an advanced way to make the linker not to depend on libatomic if it isn't actually needed. > > > 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.. :) I think the bug is in oneTBB, it is that that should be patched. Your last patch at https://github.com/uxlfoundation/oneTBB/issues/1454#issuecomment-2267455977 seems appropriate. vcmi should not need to care if oneTBB uses atomics or not. armel is not strictly at fault (although you might blame the architecture for not providing a way as easy as amd does) g++ (actually gcc has the same issue) can be partially to blame. gcc made an interface which is not too usable. Then it was reused for g++, albeit the language specification doesn't state that requirement. It *should* be improved at gcc level, but at the present time the spec is that you will need to link to libatomic, and that's what oneTBB should be doing. Best regards ¹ Ok, after writing this whole email, maybe a bit 😅
