qsbase/qs

Linking to libatomic required on 32-bit platforms

Closed this issue · 4 comments

* installing *source* package ‘qs’ ...
** using staged installation
checking for pkg-config... /opt/local/bin/pkg-config
zstd 1.5.4 library detected -- skipping zstd compilation
lz4 1.9.4 library detected -- skipping lz4 compilation
configure: creating ./config.status
config.status: creating src/Makevars
** libs
/opt/local/bin/g++-mp-12 -std=gnu++14 -I"/opt/local/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -DRCPP_USE_UNWIND_PROTECT -DRCPP_NO_RTTI -DRCPP_NO_SUGAR -I. -I/opt/local/include -I/opt/local/include  -I'/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include' -I'/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/RApiSerialize/include' -I'/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/stringfish/include' -isystem/opt/local/include/LegacySupport -I/opt/local/include   -fPIC  -pipe -Os -arch ppc  -c RcppExports.cpp -o RcppExports.o
/opt/local/bin/g++-mp-12 -std=gnu++14 -I"/opt/local/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -DRCPP_USE_UNWIND_PROTECT -DRCPP_NO_RTTI -DRCPP_NO_SUGAR -I. -I/opt/local/include -I/opt/local/include  -I'/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/Rcpp/include' -I'/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/RApiSerialize/include' -I'/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library/stringfish/include' -isystem/opt/local/include/LegacySupport -I/opt/local/include   -fPIC  -pipe -Os -arch ppc  -c qs_functions.cpp -o qs_functions.o
/opt/local/bin/g++-mp-12 -std=gnu++14 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/opt/local/Library/Frameworks/R.framework/Resources/lib -Wl,-headerpad_max_install_names -Wl,-rpath,/opt/local/lib/libgcc -L/opt/local/lib -lMacportsLegacySupport -arch ppc -o qs.so RcppExports.o qs_functions.o -L. -lpthread -L/opt/local/lib -lzstd -L/opt/local/lib -llz4 -F/opt/local/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
installing to /opt/local/var/macports/build/_opt_PPCRosettaPorts_R_R-qs/R-qs/work/qs/qs.Rcheck/00LOCK-qs/00new/qs/libs
** R
** data
*** moving datasets to lazyload DB
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘qs’ in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/opt/local/var/macports/build/_opt_PPCRosettaPorts_R_R-qs/R-qs/work/qs/qs.Rcheck/00LOCK-qs/00new/qs/libs/qs.so':
  dlopen(/opt/local/var/macports/build/_opt_PPCRosettaPorts_R_R-qs/R-qs/work/qs/qs.Rcheck/00LOCK-qs/00new/qs/libs/qs.so, 6): Symbol not found: ___atomic_store_8
  Referenced from: /opt/local/var/macports/build/_opt_PPCRosettaPorts_R_R-qs/R-qs/work/qs/qs.Rcheck/00LOCK-qs/00new/qs/libs/qs.so
  Expected in: dynamic lookup

Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/opt/local/var/macports/build/_opt_PPCRosettaPorts_R_R-qs/R-qs/work/qs/qs.Rcheck/qs’

The fix would be passing -latomic in Makevars.in conditional on GCC being the compiler and, preferably, on 32-bit platform (or implementing a test for atomics with/without libatomic). Otherwise it is IMO acceptable to link it just conditional on GCC.

Linking to libatomic seems to be required only in some architectures. So far, only this one has been identified (well, not entirely; we would need further details about your platform, @barracuda156), and therefore the inclusion of -latomic should be restricted to this platform to avoid breaking other setups that were working perfectly fine.

@Enchufa2 AFAIK, ppc, arm and mips need this for 32-bit versions of archs. I can only test ppc personally, no hardware for the rest. My platform is Darwin.

A quick googling shows that the issue is nothing specific to my platform though:
protocolbuffers/protobuf#5219
arvidn/libtorrent#5117

e5bb578 will likely fail to have a desired effect, since we need to check specifically 8-byte atomics.