On 27/01/2025 18:07, Ian Lance Taylor wrote: > Richard Earnshaw <rearn...@arm.com> writes: > >> Older versions of the Arm architecture lack support for __sync >> operations directly in hardware and require calls into appropriate >> operating-system hooks. But such hooks obviously don't exist in a >> freestanding environment. >> >> Consquently, it is incorrect to assume during configure that such >> functions will exist and we need a configure-time check to determine >> whether or not these routines will work. >> >> libbacktrace: >> >> * configure.ac: Always check if the compiler supports __sync >> operations. >> * configure: Regenerated. >> --- >> >> A consequence of this assumption that these functions 'just work' (TM) >> is that we build libbacktrace with threading support, but that then >> fails at link time when we find out that they do not. I'm not sure I >> really understand why we can assume that having with_target_subdir set >> is enough to assume that the operations exist: it isn't for Arm and it >> looks like it wasn't for hpux either. Perhaps the whole logic here >> needs reconsideration... > > My understanding was that libatomic would provide implementations of the > __sync operations where required. I guess that is not always the case, > though I don't understand why that should be.
libatomic will only be built if the target system supports it. For Arm I get (from the top-level Makefile): configure:3312: checking for libatomic support configure:3318: result: no And then we never even try to configure it. I think that test is done before we even start to build the compiler, so it would be very difficult to even test if the selected architecture could support atomic operations. I need to investigate whether there is anything I can do about that specifically for Arm, but the general test applies to all platforms, so perhaps my test should be generalized further. > > In any case, this patch is fine. > Thanks, I'll push that for the moment, at least it should give me a linkable libbacktrace for now. R.
