Mark, I also have had a lot of difficulty using cmake in the Cray computing environment (Cray XE6). My team has given up on autodetection of the build environment. Instead we use cmake in a cross compiling environment (http://www.cmake.org/Wiki/CMake_Cross_Compiling), where we manually specify CMAKE_SYSTEM_NAME, CMAKE_[C|CXX|Fortran]_COMPILER, MPIEXEC, MPI_[C|CXX|Fortran]_LIBRARIES, etc. This seems to be the most reliable way of building with all of the Cray wrapper scripts.
Obviously, the above comment doesn't address your specific issue. However, I wanted to voice my solution here for the benefit of other mailing list readers or the cmake dev team. If someone has a robust way of using cmake's autodetect features under the Cray development environment I would like to know how to make that work! -kt ________________________________ From: CMake [cmake-boun...@cmake.org] on behalf of Mark Abraham [mark.j.abra...@gmail.com] Sent: Tuesday, November 18, 2014 8:18 AM To: cmake@cmake.org Subject: [CMake] issues with static linking and Intel compiler on Crays Hi, I have two proposals for fixing issues with CMake generating suitable command lines for static linking on Cray supercomputers when using Intel as the base compiler. I hope I'm posting to the right list for discussion. Happy to switch to cmake-developers or Mantis. :-) Summary: The default Linux-Intel.cmake platform file adds -rdynamic to the command line for compiling the test for whether the toolchain works, which can fail if the toolchain isn't set up to deal with that Background: Cray provides a wrapper compiler that handles things like MPI and CUDA, and that wrapper compiler can be configured to use the Gnu, Intel or Cray compilers as their base. The wrapper can also be configured to require the use of static linking. This requirement can be side-stepped with "export XTPE_LINK_TYPE=dynamic", but this doesn't mean that a suitable library exists. Symptoms: On Archer (Cray XC30 in Edinburgh) with CMake 2.8.12 (or pre-3.1 CMake git master) I get: debug trycompile on -- The C compiler identification is Intel 14.0.0.20140805 -- The CXX compiler identification is Intel 14.0.0.20140805 -- Check for working C compiler: /opt/cray/craype/2.2.0/bin/cc -- Check for working C compiler: /opt/cray/craype/2.2.0/bin/cc -- broken CMake Error at /home2/y07/y07/cmake/2.8.12-i386/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/opt/cray/craype/2.2.0/bin/cc" is not able to compile a simple test program. ... /opt/cray/craype/2.2.0/bin/cc CMakeFiles/cmTryCompileExec3645868218.dir/testCCompiler.c.o -o cmTryCompileExec3645868218 -rdynamic ld: dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie There may be a fair point here that the Cray and Intel machinery should not be combining to pick up stuff from /usr/lib64/gcc, but I don't see a libc in the Intel compiler installation, so maybe that is a feature after all. Using Gnu as the base compiler also generates the -rdynamic, but it copes with it. The issue for CMake is the existence of -rdynamic on the command line, when testing for basic functionality in a toolchain intended for static linking. The -rdynamic is a feature (see http://www.cmake.org/Bug/view.php?id=9985), set in the platform file, that supports some minor functionality, and when it is a problem, it can mostly be worked around by users by SET(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "") However, fixing the above problem only works if such set() commands are present in the platform file. Unfortunately, that's where the settings they are working around are made... Solutions could be: 1) We could introduce a specific platform files for Linux-Intel-Cray-${lang}-static (in CMake or in an end-user application), just to make sure -rdynamic isn't set by default. This permits the test for compiler functionality to pass, and as a side effect, avoids users of the platform file needing to set this in their CMakery. 2) The attached patch (based on CMake git master) allows CMake to recognize a situation when there's no linking going on, and to avoid adding linking flags. However, it is general to all platforms and calls to generate linking command lines. I don't know whether this is a good idea, because it could affect other platforms that depend on such behaviour for linking system libraries, etc. How good is the CMake CI setup? :-) If so, maybe some kind of policy setting might be needed. Are there other options, or issues I haven't considered? Regards, Mark
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
