32-bit archs should link to libatomic when using GCC

[barracuda156]

/opt/local/bin/g++-mp-12 -pipe -Os -DNDEBUG -I/opt/local/include -D_GLIBCXX_USE_CXX11_ABI=0 -arch ppc -mmacosx-version-min=10.6 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names CMakeFiles/clasp.dir/main.cpp.o -o ../bin/clasp  -Wl,-rpath,/opt/local/lib ../lib/libclasp.a ../lib/libpotassco.a 
Undefined symbols:
  "___atomic_fetch_add_8", referenced from:
      __ZN5Clasp18SharedMinimizeData11resetBoundsEv in libclasp.a(minimize_constraint.cpp.o)
  "___atomic_fetch_or_8", referenced from:
      __ZN5Clasp2mt13ParallelSolve9exceptionEjRNS_14SingleOwnerPtrIKN6bk_lib10pod_vectorINS_7LiteralESaIS5_EEENS_12DeleteObjectEEENS1_9ErrorCodeEPKc in libclasp.a(parallel_solve.cpp.o)
  "___atomic_compare_exchange_8", referenced from:
      __ZN5Clasp18SharedMinimizeData8incLowerEjx in libclasp.a(minimize_constraint.cpp.o)
  "___atomic_fetch_sub_8", referenced from:
      __ZN5Clasp2mt13ParallelSolve10SharedData11requestWorkERKNS_6SolverE in libclasp.a(parallel_solve.cpp.o)
  "___atomic_store_8", referenced from:
      __ZN5Clasp18SharedMinimizeData8setLowerEjx in libclasp.a(minimize_constraint.cpp.o)
      __ZN5Clasp18SharedMinimizeData11resetBoundsEv in libclasp.a(minimize_constraint.cpp.o)
      __ZN5Clasp2mt13ParallelSolve9initQueueEv in libclasp.a(parallel_solve.cpp.o)
      __ZN5Clasp2mt13ParallelSolve10SharedData5resetEPNS_13SharedContextE in libclasp.a(parallel_solve.cpp.o)
      __ZN5Clasp2mt13ParallelSolve10SharedData5resetEPNS_13SharedContextE in libclasp.a(parallel_solve.cpp.o)
  "___atomic_load_8", referenced from:
      __ZN5Clasp18SharedMinimizeData7setModeENS_14MinimizeMode_t4ModeEPKxj in libclasp.a(minimize_constraint.cpp.o)
      __ZNK5Clasp18SharedMinimizeData5lowerEj in libclasp.a(minimize_constraint.cpp.o)
      __ZNK5Clasp2mt13ParallelSolve9hasErrorsEv in libclasp.a(parallel_solve.cpp.o)
      __ZN5Clasp2mt13ParallelSolve10SharedData11requestWorkERKNS_6SolverE in libclasp.a(parallel_solve.cpp.o)
  "___atomic_exchange_8", referenced from:
      __ZN5Clasp2mt13ParallelSolve10SharedData11requestWorkERKNS_6SolverE in libclasp.a(parallel_solve.cpp.o)
ld: symbol(s) not found
collect2: error: ld returned 1 exit status

[rkaminsk]

Usually, I'ld pass the -threads option. Clasp uses find_package(Threads REQUIRED) if multi-threading is enabled, which should in theory add it. Maybe this is a cmake problem?

[barracuda156]

-libatomic is not pulled in automatically by GCC, AFAIK, not in general case. Maybe for some specific targets.

And no, this is not a CMake-specific issue. At least, I get the same problem with other build systems too, whenever software uses 8-byte atomics which are not supported on a hardware level. For sure with makefiles/autotools.

[rkaminsk]

-libatomic is not pulled in automatically by GCC, AFAIK, not in general case. Maybe for some specific targets.

And no, this is not a CMake-specific issue. At least, I get the same problem with other build systems too, whenever software uses 8-byte atomics which are not supported on a hardware level. For sure with makefiles/autotools.

Have you tried adding option -threads to the cxx flags (-DCMAKE_CXX_FLAGS=-threads)? Otherwise, clasp already checks if libatomic is necessary. But only for clang.

[barracuda156]

Otherwise, clasp already checks if libatomic is necessary. But only for clang.

This is strange. Clang does not normally use libatomic – I am not even sure it can. It is a GCC library.

Passing -latomic fixes the problem, expectedly, but it would be nice the have it fixed via a check in CMakeLists rather than a local hack in Macports.

P. S. -threads looks to me like something target-specific. I do not think Darwin has it. There are -pthread and -lpthread.

[rkaminsk]

This is strange. Clang does not normally use libatomic – I am not even sure it can. It is a GCC library.

On linux it can use all the gcc libraries. I guess it was needed for some platform.

I mixed it up the -threads option. It would be too simple to have one option for all targets. I was thinking of -pthread.

Probably, we simply have to adjust the condition when to check for libatomic. I would think that changing

if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND CMAKE_USE_PTHREADS_INIT

to

if (CMAKE_USE_PTHREADS_INIT)

will do the trick. I don't see any harm to do this unconditionally for anything pthread compatible.

[BenKaufmann]

@rkaminsk Agreed. Adjusted the check accordingly in dev.

@barracuda156 Does this fix the issue for you?

[rkaminsk]

P. S. -threads looks to me like something target-specific. I do not think Darwin has it. There are -pthread and -lpthread.

Adding -pthread might have worked too:

  -pthread
      Define additional macros required for using the POSIX threads library.  You should use this option
      consistently for both compilation and linking.  This option is supported on GNU/Linux targets, most
      other Unix derivatives, and also on x86 Cygwin and MinGW targets.

[barracuda156]

I will check this today. I think -pthread does not do.

[barracuda156]

@rkaminsk @BenKaufmann Changing if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND CMAKE_USE_PTHREADS_INIT to if (CMAKE_USE_PTHREADS_INIT) as suggested above fixes the problem, everything builds fine then, -latomic is passed.

[barracuda156]

Perhaps backport b08da9a into the master?

[BenKaufmann]

Perhaps backport b08da9a into the master?

Currently, clasp uses a very simple branching model where master corresponds to the current release (3.3.9 atm) and dev contains the ongoing work on the next release (probably 3.3.10). Hence, the commit will only end up in master with the next release.

[barracuda156]

@BenKaufmann Got it, thank you!