cmake 126.96.36.199 breaks linking on Mac OS X.
On Mac OS X, binaries are broken during "make install" using cmake version 188.8.131.52.
Downgrading to cmake 184.108.40.206 or GMX_GPU=OFF (then tested compiling with clang) are working walk-arounds.
Possible fix (but not tested): http://cmake.org/gitweb?p=cmake.git;a=commit;h=08141a5
Fixed CMake 2.8.12+ CUDA dylib bugs and warnings on OS X
This patch fixes up a number of minor compilation issues
with CUDA on OS X. The STRICT_ANSI define has been
added to make CUDA work with gcc version 4.8 and 4.9,
a dummy variable has been added to the dummy c++ gpu utils
file to avoid warnings about empty objects, and we now
properly handle both RPATH (newer CMake) and INSTALL_NAME_DIR
(older CMake) without warnings. CMake-2.8.12 introduced
a bug that caused Gromacs executables to be malformed since
the rpath to the CUDA libraries was added twice. This is
caused by fairly deep internal changes in CMake, but it has
been worked around by removing the rpath (which FindCUDA.cmake
only adds on OS X) manually for CMake>2.8.11.
#2 Updated by Erik Lindahl over 5 years ago
- Status changed from New to Feedback wanted
- Priority changed from High to Normal
Anders - please provide more details.
The description about testing with clang instead hints that you are using gcc or something else in the first place. Exactly what configuration settings were you using? What computer are you compiling on? OS version? CUDA version? Compiler versions?
It is not clear to me that this is actually a CMake, rather than Cuda, bug; builds both with clang and gcc work fine for me without Cuda.
The Mac CUDA situation is unfortunately a mess since NVIDIA only supports old versions of GCC while the system default clang does not support OpenMP.
#3 Updated by Anders Gabrielsson over 5 years ago
As far as I can remember, I tried building (mdrun) using then up-to-date versions of both apple-clang and macports-gcc along with CUDA 6.
The thing is that the binaries in the build tree works fine, but the ones put in your path after 'make install' have broken dylib headers. (otool cant read them anyway.)
This makes me think it is related to the new rpath features of cmake 2.8.12 for macos. http://www.kitware.com/blog/home/post/510
I can take a few minutes to try and reproduce this with my current setup.