Hello Ward,
We’ve managed to get CMake to build on our local filesystem, but when I load
it, it falls back to the system installed gcc instead of the intel toolchain:
/tmp/hello_world> module list
Currently Loaded Modulefiles:
2) GCC/4.8.3
3) icc/2013.5.192-GCC-4.8.3
4) ifort/2013.5.192-GCC-4.8.3
5) iccifort/2013.5.192-GCC-4.8.3
6) impi/4.1.3.049-iccifort-2013.5.192-GCC-4.8.3
7) iimpi/5.5.3-GCC-4.8.3
8) imkl/11.1.2.144-iimpi-5.5.3-GCC-4.8.3
9) intel/2014b
10) ncurses/5.9-intel-2014b
11) CMake/3.0.0-intel-2014b
/tmp/hello_world> cmake .
-- The C compiler identification is GNU 4.4.7
-- The CXX compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/hello_world
Since you mention it below, I’m wondering: shouldn’t it be using the intel
compilers instead?
In the logfile for CMake, it shows:
loading initial cache file
/tmp/CMake-easybuild/CMake/3.0.0/intel-2014b/cmake-3.0.0/Bootstrap.cmk/InitialCacheFlags.cmake
-- The C compiler identification is Intel 13.1.0.20130607
-- The CXX compiler identification is Intel 13.1.0.20130607
-- Check for working C compiler:
/apps/antwerpen/ivybridge/sl6/icc/2013.5.192-GCC-4.8.3/bin/intel64/icc
-- Check for working C compiler:
/apps/antwerpen/ivybridge/sl6/icc/2013.5.192-GCC-4.8.3/bin/intel64/icc -- works
It finds the icc executable when building the module, so why isn’t it being
used after the module is loaded?
-- Thanks for your reply,
Franky
Op 28-okt.-2014, om 12:06 heeft Ward Poelmans <[email protected]> het
volgende geschreven:
> On Tue, Oct 28, 2014 at 12:04 PM, Pablo Escobar Lopez
> <[email protected]> wrote:
>> I verified it when I tried the workaround and it seems to work fine, at
>> least in this case.
>
> That's because you are using a gcc toolchain and it is in the path. I
> suspect this would fall back to system gcc with an ictce toolchain.
>
> Ward
