gromacs-toolchain.cmake file does not work on OS X
The generated toolchains file, now installed to share/cmake/gromacs/gromacs-toolchain.cmake in the GROMACS installation, is insufficient to reproduce the GROMACS build environment on Mac OS X. (This means that requiring the file for the gmxapi setup.py breaks the gmxapi Python package installation.) To reproduce, it is only necessary to try to use the file to configure GROMACS again.
cmake path/to/gromacs-repo -DCMAKE_INSTALL_PREFIX=$HOME/gromacs
cmake path/to/gromacs-repo -D -DCMAKE_TOOLCHAIN_FILE=$HOME/gromacs/share/cmake/gromacs/gromacs-toolchain.cmake
CMake Error at src/api/cpp/CMakeLists.txt:52 (add_library):
Attempting to use @rpath without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being
set. This could be because you are using a Mac OS X version less than 10.5
or because CMake's platform configuration is corrupt.
Do not use gromacs-toolchain in darwin gmxapi builds.
Add workaround for toolchain issue on OS X.
Improve uniformity of OS X CMake configuration.
- Update the toolchains file to work with OS X.
- Use uniform OS X deployment target and architecture.
- Use CMake toolchain for OS X Python package installations.
#1 Updated by Mark Abraham 5 months ago
Yes. Presumably, since the toolchain file implies cross-compiling, CMake doesn't do the automatic environment detection that it normally would. Usually, setting CMAKE_OSX_DEPLOYMENT_TARGET and CMAKE_OSX_ARCHITECTURES are sufficient to configure the dynamic linking stuff correctly.
While I think we need the toolchain file for true cross-compilation scenarios (Cray HPC systems, etc), it may be that this isn't the right tool for getting the GROMACS-compatible compilers. If we want to stick with CMake machinery rather than a more generic scriptlet or configuration file, we could consider providing a stripped down CMakeCache file to bootstrap from with "-C"
#5 Updated by Eric Irrgang 4 months ago
Mark Abraham wrote:
I don't think anybody has worked on this.
@Eric does it still repro?
I rebased https://gerrit.gromacs.org/c/gromacs/+/13123 locally onto master and confirmed that the problem is still the same.
Change-Id: I96a8242b14c86abd4926b6abf5a401c37953b9bc was just a workaround.