32-bit archs should link to libatomic when using GCC
barracuda156 opened this issue · comments
/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
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?
-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.
-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.
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
.
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.
@rkaminsk Agreed. Adjusted the check accordingly in dev.
@barracuda156 Does this fix the issue for you?
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.
I will check this today. I think -pthread
does not do.
@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.
Perhaps backport b08da9a into the master?
@BenKaufmann Got it, thank you!