Closed Romendakil closed 3 years ago
@Romendakil would you be so kind and test this solution https://github.com/AIDASoft/DD4hep/pull/751
Hi Marko @petricm , I exchanged the corresponding 3 lines in LCIO's ilcsoft_default_cxx_flags.cmake, and it builds and tests fine. DD4HEP I've never built up to now. Cheers, JRR (Juergen Reuter)
Thank you for the quick response. I did not mean that you would need compile DD4hep, but if you could tests the few lines from my DD4hep PR (then we can also use it here).
Just replace
with
We don't have any setup like your for testing.
you only need to remove dd4hep_debug()
lines
Yep, that's what I did^^. It works, as I said, LCIO (2.15.04) compiles, and the test-suite passes.
Oh sorry misunderstood, thank you very much for checking this.
!!!IMPORTANT!!!: To facilitate faster and easier response to your issue please provide in addition to the description of the issue also the following information
Hi, this is halfway a question or a discussion. To build LCIO on macOS with gcc/g++ instead of the XCode/System clang, I always have to comment out the lines
IF( "${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU" ) LIST( APPEND COMPILER_FLAGS -Wl,-no-undefined ) ENDIF()
in ilcsoft_default_cxx_compiler_flags.cmake because the g++ (which is the default linker in that case) does not know this flag:
/usr/local/bin/g++ -fdiagnostics-color=auto -Wl,-no-undefined -Wno-non-virtual-dtor -Wuninitialized -Wno-long-long -pedantic -Weffc++ -Wshadow -Wextra -Wall -O2 -g -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk -dynamiclib -Wl,-headerpad_max_install_names -current_version 0.0.2 -o ../lib/libsio.0.0.2.dylib -install_name @rpath/libsio.0.0.dylib CMakeFiles/sio.dir/src/api.cc.o CMakeFiles/sio.dir/src/block.cc.o CMakeFiles/sio.dir/src/buffer.cc.o CMakeFiles/sio.dir/src/compression/zlib.cc.o CMakeFiles/sio.dir/src/exception.cc.o CMakeFiles/sio.dir/src/io_device.cc.o CMakeFiles/sio.dir/src/memcpy.cc.o CMakeFiles/sio.dir/src/version.cc.o /opt/local/lib/libz.dylib ld: unknown option: -no-undefined
I think the reason is the following: when you install gcc with one of the default tools on macOS (like homebrew, Macports or fink) it installs also a gcc-affine linker version (ld64 in /opt/local/bin) which understands this option. If you build gcc yourself, it still uses /usr/bin/ld, so the system linker, in which case -Wl,-undefined,error would be the correct choice. Of course, this is partially in the user responsibility, but I think there is no cmake option that I could use to specify that flag. CMAKE_EXE_LINKER_FLAGS seems like the parameter to set, but it looks I cannot set this. Could you check for the linker? As mentioned above, this is not really a bug in my eyes, but a special case for user setups. But maybe there is a fast solution.