Hi,
When developing software (in contrast to simply building and installing
it with EB) it makes sense to leverage the existing toolchains for
setting up a build environment. E.g. I load foss/2017b and other needed
EB-built dependencies while developing and use CMake to build by hand.
When the package gets to a stable point creating an EB config is then
(relatively) easy and predictable, based on the loaded modules used.
Rebuilding by hand is also a lot quicker than doing a full EB build and
install each time.
But loading a toolchain like foss/2017b doesn't completely set up the
environment in a way that makes it directly usable by CMake and friends.
Particularly, CC and CXX are not set so it's up to the build tool to
figure out which compiler to use.
CMake does this somewhat silly in that it searches for (in order) cc,
gcc, cl, bcc, ... when CC is not set (and similarly c++, g++, aCC, cl,
... when CXX is not set). But this is a breadth-first search of "cc" in
a set of directories. So in our case it actually finds /usr/bin/cc (and
/usr/bin/c++ next to it) which are old, GCC 4.8.5, and it doesn't find
the foss/2017b binaries. This appears to be because GCC installations
don't contain the "cc" command (even though they have a "c++" one),
which is what CMake searches for first.
Setting CC and CXX to the foss/2017b compilers will fix this, which kind
of makes me wonder why these aren't set by default when loading
GCC(core) and similar compiler modules? Has this ever been discussed?
Regards,
Paul
--
Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | [email protected] | www.surfsara.nl |
