~breakfastquay/rubberband#28: 32-bit platforms need explicit linking to libatomic

Otherwise the following happens:

Undefined symbols:
  "___atomic_is_lock_free", referenced from:
      __ZN10RubberBand11R3StretcherC4ENS0_10ParametersEddNS_3LogE in librubberband_objlib.a(src_finer_R3Stretcher.cpp.o)
  "___atomic_load_8", referenced from:
      __ZNK10RubberBand11R2Stretcher18getSamplesRequiredEv in librubberband_objlib.a(src_faster_R2Stretcher.cpp.o)
      __ZNKSt6atomicIdEcvdEv in librubberband_objlib.a(src_finer_R3Stretcher.cpp.o)
      __ZN10RubberBand11R2Stretcher18testInbufReadSpaceEm in librubberband_objlib.a(src_faster_StretcherProcess.cpp.o)
      __ZN10RubberBand11R2Stretcher10writeChunkEmmb in librubberband_objlib.a(src_faster_StretcherProcess.cpp.o)
      __ZN10RubberBand11R2Stretcher10writeChunkEmmb in librubberband_objlib.a(src_faster_StretcherProcess.cpp.o)
      __ZN10RubberBand11R2Stretcher13ProcessThread3runEv in librubberband_objlib.a(src_faster_StretcherProcess.cpp.o)
      __ZNK10RubberBand11R2Stretcher9availableEv in librubberband_objlib.a(src_faster_StretcherProcess.cpp.o)
  "___atomic_store_8", referenced from:
      __ZN10RubberBand11R2Stretcher7processEPKPKfmb in librubberband_objlib.a(src_faster_R2Stretcher.cpp.o)
      __ZNSt6atomicIdEaSEd.isra.0 in librubberband_objlib.a(src_finer_R3Stretcher.cpp.o)
      __ZN10RubberBand11R2Stretcher11ChannelData5resetEv in librubberband_objlib.a(src_faster_StretcherChannelData.cpp.o)
ld: symbol(s) not found

Status: REPORTED
Submitter: ~barracuda156
Assigned to: No-one
Submitted: 1 year, 8 months ago
Updated: 1 year, 8 months ago
Labels: No labels applied.

~cannam 1 year, 8 months ago*

See also https://github.com/breakfastquay/rubberband/issues/62 which remains without resolution.

Which platform and build chain are you using? My own 32-bit builds are currently working fine without -latomic, and I have no idea how one would determine whether to add it explicitly or not.

The Godot tracker linked from the Github issue also refers to failures caused by adding -latomic on platforms that didn't need it, so I don't want to introduce it unilaterally.

Perhaps there is a clear example of how to handle this somewhere? If so, nobody commenting on the other issue or the ones linked to it seems to have found it (and, needless to say, nor have I).

I would happily accept a patch if it works across all test platforms and comes with a convincing explanation of why it is correct.

~barracuda156 1 year, 8 months ago

I do not know how to write a test for meson, but what is needed is to test native (hardware) support for 8-byte atomics, if that fails, test the same with libatomic linking, if it succeeds, pass -latomic flag, if it also fails, err out with a message that libatomic is needed but missing. Multiple ports have such tests implemented for CMake. A simpler, heuristic-based solution would be to test for compiler and bitness, and pass -latomic whenever it is GCC on 32-bit platform. I am not sure how Intel handles atomics; ppc requires libatomic for sure, arm and mips seems to require it too.

~cannam 1 year, 8 months ago

A simpler, heuristic-based solution would be to test for compiler and bitness, and pass -latomic whenever it is GCC on 32-bit platform

That's the sort of thing I want to avoid, because the heuristic would seem to have both false positives and false negatives

The other issue linked was for a 64-bit system using Clang, not a 32-bit one using GCC, and it originally failed without -latomic (albeit the reporter then found a fix at system level)

My own builds on 32-bit systems using GCC have not needed -latomic

I should have another scout around and see whether there's a Meson incantation to solve this - although I also don't really want to depend on a newer version of Meson!

Are you confident that this isn't an issue with the GCC/glibc combo? Should the runtime not be providing libatomic itself if the atomics are not intrinsic?

~breakfastquay 1 year, 8 months ago*

I've added a test in the Meson build, in a branch called libatomic-check. I'd appreciate feedback - especially as I haven't actually seen this failure myself!

The test works (if it works) by using the C++ compiler to compile and link the same thing that the actual Rubber Band code uses, namely declaring variables of types std::atomic<double> and std::atomic<int> and calling is_lock_free on each - since that is the symbol that both bug reports had in common.

~barracuda156 1 year, 8 months ago*

The other issue linked was for a 64-bit system using Clang, not a 32-bit one using GCC, and it originally failed without -latomic
I don’t know what monstrous build was that, but Clang is supposed to use its own compiler-rt atomics, not GCC’s libatomic :)
My own builds on 32-bit systems using GCC have not needed -latomic
If it is i386, I am not sure. I am sure that passing -latomic won’t break anything though. On ppc it is necessary.
Should the runtime not be providing libatomic itself if the atomics are not intrinsic?
No, GCC does not add it automatically, and it is a conscious decision by upstream.