[CMake] issues with static linking and Intel compiler on Crays

[Mark Abraham]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141118/7dbd40af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Stop-compiler-tests-appending-unnecessary-linking-fl.patch
Type: text/x-patch
Size: 3410 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20141118/7dbd40af/attachment-0001.bin>