Build failure for targets without native 64bit atomics support
Closed this issue · 7 comments
OpenAL 1.24.0 compilation fails on static_assert:
Line 12 in c204b31
when targeting architecture without native support for 64 bit atomics ie ARM v6 and lower:
/home/users/builder/rpm/BUILD/openal-soft-1.24.0/core/device.cpp:12:54: error: static assertion failed
12 | static_assert(std::atomic<std::chrono::nanoseconds>::is_always_lock_free);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~That could be an issue for backends that use the mixer in real-time callbacks, which need 64-bit atomic load/stores to be lock-free (which for Android could be the Oboe backend). Unless the platform does support lock-free atomic 64-bit loads and stores, or "relaxed" 64-bit loads and stores, and simply can't guarantee all other atomic operations are lock-free.
Any chance to turn this hard requirement into something optional?
Even if it's kept as a hard requirement (which I hope won't be the case), the proper place to check such thing would be at CMake level.
Any chance to turn this hard requirement into something optional?
Maybe, but it's odd. CMPXCHG8B has been supported on x86 since at least the Pentium for 64-bit atomic compare-exchange (which can be used to implement any of the other missing 64-bit atomic operations lock-free). It's surprising that a CPU that's still relevant today could lack similar functionality.
It's probably possible to change it to not rely on a 64-bit atomics, at least for 32-bit systems (pointers and size_t can't be avoided with atomics, so if they're 64-bit, it will still be a problem).
The issue arises in older ARM processors, though.
Should be fixed with commit bc90872.
That fixed it, thank you!