5 Feb
2019
5 Feb
'19
10:04 a.m.
Hi All, - sorry for wrong information about clang and Thank You Jonas! for corrections! - more comments inline On 02/04/2019 09:52 AM, Hahnfeld, Jonas wrote: > 1) CentOS 7 comes with GCC 4.8.5 and the matching libstdc++. This works for most > of C++11, but doesn't support C++14 nor C++17. ... And this situation will not be changed: we will continue to use a industry-proven OS distribution which will always stay 5y beyond bleeding edge of development. > This will use libc++ and everything is fine (as long as it's implemented in > Clang 6.0 that's already one year old; there's an installation of Clang 7.0, but > that's not the default yet). Correction: in the new environment as to be found on login18-1 now the clang/7.0 is set to be the default version. > Unfortunately just loading a newer GCC doesn't work for Clang, it will still use > libstdc++ from GCC 4.8.5. You can override the GCC installation via a command > line flag: > # module switch intel gcc/8 > # module load clang > # $CXX -stdlib=libstdc++ --gcc-toolchain=$GCC_ROOT -std=c++17 optional.cpp > (Note that the order is important here: First load GCC and then Clang in a > second step; this is basically equivalent to what Paul described last week using > $ module purge) Please use the described way with 'module purge' and loading the needed modules in the correct order! The commands Jonas wrote would give you a working environment for Clang with support of new C++Std, *but broken MPI environment* (still configured to use GCC as the MPI is loadrd after GCC and not Clang. Please note that - the last compiler in the module list is the 'leading' one ($CC $CXX $FC envvars set to it, will also be found by most Sw configure environments like autotools or Cmake) - the MPI configure itself according to last-compiler-loaded So loading a compiler *after* MPI will change the active compiler but will not reconfigure MPI. see the difference: > $ module switch intel gcc/8 ; module load clang; module list > Currently Loaded Modulefiles: > 1) DEVELOP 2) gcc/8 3) intelmpi/2018 4) clang/7.0 active compiler: clang (has access to gcc/8 headers), but intelmpi after gcc => for GCC! $ module purge; module load DEVELOP gcc/8 clang intelmpi; module list > 1) DEVELOP 2) gcc/8 3) clang/7.0 4) intelmpi/2018 Yes this is annoying and could lead to broken environment. On the other hand sometimes you *need* a lot of flexibility (there are some projects using a bunch of compilers for compile parts of the code). Note that we planned to change the entire module environment implementation also with plan to make the chiearchical structure more robust - we still plan it for some near future. > The following also works: > # module switch intel clang > # $CXX -stdlib=libstdc++ --gcc-toolchain=/usr/local_rwth/sw/gcc/8.2.0/ > -std=c++17 optional.cpp > > Please note that this is not how we recommend using the Clang installation: We > chose libc++ to avoid mismatches and all kinds of subtle errors I've described > above. So while this setup might work, it's possible to break with the next set > of module files and / or the next major update of either GCC or Clang. Just my 5 pennys: there are many ways to configure and to use the environment and software: - the default one (we provide for you and give full support) - w/other modules (we provide for you but do NOT recommend to load it ALWAYS) - w/additional (own) modules... - w/bunch of other modules... - w/bunch of other modules preloaded in the environment... - w/additionas Sw 'just added to own environment' - w/sourced scripts 'from Joe' - w/sourced scripts 'I do not know what that is but my friend also sourced that' - .... The deeper in the list is, the more interesting and challenging your environment is. We spent hours of time and gallons of coffee by debugging exciting trouble tickets just in order to find out - in many many cases - *how* the user shoot himself into the feet this time. Note that the module system keeps changing all over the time. So commands to load any version XYZ of some Sw may became unavailable after some time, or even worse: it could stay working but load an old version where a newer one is available... This is the main issue with environment changes in the user profile - once working, later it broken and the user did not get any notice of it as he purged all the output to /dev/null, of course... So if you like to modify our environment, you're welcome BUT - change things you really need and not 'maybe later' or 'why not', - *understand what you do* ... - keep the changes be verbose! Check from time to time it is still working as desired! Have a nice day, Paul Kapinos -- Dipl.-Inform. Paul Kapinos - High Performance Computing, RWTH Aachen University, IT Center Seffenter Weg 23, D 52074 Aachen (Germany) Tel: +49 241/80-24915