Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Undefined linker flag -Wl,-no-undefined when compiling with GNU gcc/g++ on macOS #118

Closed
Romendakil opened this issue Oct 28, 2020 · 6 comments · Fixed by #121
Closed

Undefined linker flag -Wl,-no-undefined when compiling with GNU gcc/g++ on macOS #118

Romendakil opened this issue Oct 28, 2020 · 6 comments · Fixed by #121

Comments

@Romendakil
Copy link

!!!IMPORTANT!!!: To facilitate faster and easier response to your issue please provide in addition to the description of the issue also the following information

  • OS version: macOS Darwin 10.15.7
  • Compiler version: GCC 10.2
  • Package version: v2.15.04

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.

@petricm
Copy link
Contributor

petricm commented Nov 20, 2020

@Romendakil would you be so kind and test this solution AIDASoft/DD4hep#751

@Romendakil
Copy link
Author

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)

@petricm
Copy link
Contributor

petricm commented Nov 20, 2020

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

IF( "${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU" )
LIST( APPEND COMPILER_FLAGS -Wl,-no-undefined )
ENDIF()

with

https://github.com/petricm/DD4hep/blob/65472014d899311a3245b6982543769c4f640a2b/cmake/DD4hepBuild.cmake#L83-L105

We don't have any setup like your for testing.

@petricm
Copy link
Contributor

petricm commented Nov 20, 2020

you only need to remove dd4hep_debug() lines

@Romendakil
Copy link
Author

Yep, that's what I did^^. It works, as I said, LCIO (2.15.04) compiles, and the test-suite passes.

@petricm
Copy link
Contributor

petricm commented Nov 20, 2020

Oh sorry misunderstood, thank you very much for checking this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants