Closed computerquip closed 1 year ago
@computerquip Even with this change, I'm still having issues with linking voglgen
(and other programs).
Few points:
(1) gcc
and g++
are being used to compile. Linking command is:
cat src/voglgen/CMakeFiles/voglgen.dir/link.txt
/usr/bin/g++ -DVOGL_USE_STB_MALLOC=0 -fno-omit-frame-pointer \
-march=corei7 -Wno-unused-parameter -Wno-unused-function -fno-strict-aliasing \
-fno-math-errno -fvisibility=hidden -Wno-unused-local-typedefs -fsanitize=address \
-fno-optimize-sibling-calls -DVOGL_USE_STB_MALLOC=0 -DCOMPILER_GCC=1 \
-DCOMPILER_GCCLIKE=1 -DPLATFORM_LINUX=1 -DPLATFORM_POSIX=1 \
-DPLATFORM_64BIT=1 -g -O0 -D_DEBUG -Wl,--no-undefined \
CMakeFiles/voglgen.dir/voglgen.cpp.o CMakeFiles/voglgen.dir/tinyxml2/tinyxml2.cpp.o \
-o ../../../../vogl_build/voglgen64 -rdynamic ../voglcore/libvoglcore.a -lrt -ldl
(2) clang-3.5
and clang++-3.5
do not have this problem. Link command is:
cat src/voglgen/CMakeFiles/voglgen.dir/link.txt
/usr/bin/clang++-3.5 -DVOGL_USE_STB_MALLOC=0 -Weverything \
-fdiagnostics-show-category=name -Wno-unused-macros -Wno-padded \
-Wno-variadic-macros -Wno-missing-variable-declarations -Wno-missing-prototypes \
-Wno-sign-conversion -Wno-conversion -Wno-cast-align -Wno-exit-time-destructors \
-Wno-documentation-deprecated-sync -Wno-documentation-unknown-command \
-Wno-undefined-reinterpret-cast -Wno-incompatible-pointer-types-discards-qualifiers \
-Wno-float-equal -Wno-unreachable-code -Wno-weak-vtables -Wno-extra-semi \
-Wno-disabled-macro-expansion -Wno-format-nonliteral -Wno-packed \
-Wno-c++11-long-long -Wno-c++11-extensions -Wno-nested-anon-types -Wno-pedantic \
-Wno-header-hygiene -Wno-covered-switch-default -Wno-duplicate-enum \
-Wno-switch-enum -Wno-extra-tokens -Wno-documentation -Wno-undef \
-Wno-gnu-anonymous-struct -Wno-gnu-zero-variadic-macro-arguments \
-Wno-gnu-redeclared-enum -fno-omit-frame-pointer -march=corei7 \
-Wno-unused-parameter -Wno-unused-function -fno-strict-aliasing -fno-math-errno \
-fvisibility=hidden -fsanitize=address -fno-optimize-sibling-calls \
-DVOGL_USE_STB_MALLOC=0 -DCOMPILER_CLANG=1 \
-DCOMPILER_GCCLIKE=1 -DPLATFORM_LINUX=1 -DPLATFORM_POSIX=1 \
-DPLATFORM_64BIT=1 -g -O0 -D_DEBUG -Wl,--no-undefined \
CMakeFiles/voglgen.dir/voglgen.cpp.o CMakeFiles/voglgen.dir/tinyxml2/tinyxml2.cpp.o \
-o ../../../../vogl_build/voglgen64 -rdynamic ../voglcore/libvoglcore.a -lrt -ldl
The problem appears because the pthreads library is not being linked against during the linking command. So, for the gcc/g++ case, this returns:
/usr/bin/ld: ../voglcore/libvoglcore.a(vogl_threading_pthreads.cpp.o): undefined reference to symbol 'pthread_mutexattr_settype@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
However there is no issue with using clang and clang++ to compile.
I decided to investigate the following:
(1) ${CMAKE_THREAD_LIBS_INIT}
On my system it is being set to nothing. I checked this by modifying, function(require_pthreads)
within src/build_options.cmake
; (in both the gcc and clang case)
(2) Adding -lpthreads
as an additional target for linking will allow for gcc/g++ to compile properly (this can be added within src/build_options.cmake
.
It appears that the suggested solution is from stackoverflow.
However even after making this change to the CMakeLists.txt
(within the subfolders of src
); it still doesn't build. The current working around for me is to force the linking of libpthread, as follows:
diff --git a/src/build_options.cmake b/src/build_options.cmake
index 3c44da8..6e03a48 100644
--- a/src/build_options.cmake
+++ b/src/build_options.cmake
@@ -372,7 +372,7 @@ function(require_pthreads)
else()
# Export the variable to the parent scope so the linker knows where to find the li
- set(CMAKE_THREAD_LIBS_INIT ${CMAKE_THREAD_LIBS_INIT} PARENT_SCOPE)
+ set(CMAKE_THREAD_LIBS_INIT ${CMAKE_THREAD_LIBS_INIT} pthread PARENT_SCOPE)
endif()
endfunction()
I was pleasantly surprised today to find this happening with all files in their correct location. Apparently, this is a shortcoming of cmake, requiring that the project in question including pthreads to label its project corresponding to the type of source its using, seemingly because of how it implements tests... but labeling it both CXX and C work just fine. Very weird but here's a diff of proposed changes: