Open barracuda156 opened 3 weeks ago
Thanks for the report. Would something like this work as a check? I don't have a 32-bit system handy to check on.
require_libatomic.cc:
#include <atomic>
int main( int argc, char** argv )
{
std::atomic<int> x = 0;
for (int i = 1; i < argc; ++i) {
++x;
}
return x;
}
Try to compile and link:
g++ -std=c++17 -o require_libatomic require_libatomic.cc
If not, try to compile and link:
g++ -std=c++17 -o require_libatomic require_libatomic.cc -latomic
If so, that's fairly easy to integrate into the Makefile / CMake build scripts.
@mgates3 Thank you for responding!
Checking for int does not serve the purpose, since 4-byte atomics is usually supported everywhere (and for sure on ppc at least). What may not be supported is 8-byte atomics, so we need to check for a corresponding type. (I have also seen in some tickets that RISC-V may not support 1-byte atomics, but cannot confirm that personally.)
That explains the issue better. So:
#include <atomic>
#include <cstdint>
int main( int argc, char** argv )
{
std::atomic<std::int64_t> x = 0;
for (int i = 1; i < argc; ++i) {
++x;
}
return x;
}
This works as expected (fails without libatomic, succeeds with the flag added):
36-150% /opt/local/bin/gcc-mp-14 -std=c++17 -o require_libatomic require_libatomic.cc
Undefined symbols:
"___atomic_fetch_add_8", referenced from:
__ZNSt13__atomic_baseIxEppEv in ccpntpHJ.o
"___atomic_load_8", referenced from:
__ZNKSt13__atomic_baseIxEcvxEv in ccpntpHJ.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
36-150% /opt/local/bin/gcc-mp-14 -std=c++17 -o require_libatomic require_libatomic.cc -latomic
36-150%
This is not OS-specific issue, it will fail likewise on *BSD and Linux on certain 32-bit archs (arm, ppc, likely mips).