Dear list, apparently the Clang installation is build against the headers of the default GCC 4.8.5, which limits its understanding of C++ to C++11. Would it be possible to at least target the headers of GCC5? That would at least support C++14. Of course, with GCC8.2.0 being available as well, C++17 should also be possible ;) Kind regards, Philipp -- Philipp Berger https://moves.rwth-aachen.de/people/berger/ Software Modeling and Verification Group RWTH Aachen University Phone +49/241/80-21206 Ahornstraße 55, 52056 Aachen, Germany
Paul, could you have a look? Best Marcus On 1/25/19 1:42 PM, Philipp Berger wrote:
Dear list,
apparently the Clang installation is build against the headers of the default GCC 4.8.5, which limits its understanding of C++ to C++11. Would it be possible to at least target the headers of GCC5? That would at least support C++14. Of course, with GCC8.2.0 being available as well, C++17 should also be possible ;)
Kind regards,
Philipp
_______________________________________________ claix18-slurm-pilot mailing list -- claix18-slurm-pilot@lists.rwth-aachen.de To unsubscribe send an email to claix18-slurm-pilot-leave@lists.rwth-aachen.de
-- Marcus Wagner, Dipl.-Inf. IT Center Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24383 Fax: +49 241 80-624383 wagner@itc.rwth-aachen.de www.itc.rwth-aachen.de
I met one of your HiWis today and he told me that Clang currently requires the use of LibC++ instead of LibStdc++. I discussed this internally, and for us, this is a problem as we have some dependencies that we need to link (like GLPK and other more proprietary libraries) that come pre-compiled against libstdc++. So switching to libc++ is not an (easy) option, if at all. He mentioned that getting Clang to use the more recent headers would require some "hacks" - how difficult is that? We will currently focus on GCC, but Clang is definitely a target of interest for us. Kind regards, Philipp Am 31-Jan-19 um 10:21 schrieb Marcus Wagner:
Paul, could you have a look?
Best Marcus
On 1/25/19 1:42 PM, Philipp Berger wrote:
Dear list,
apparently the Clang installation is build against the headers of the default GCC 4.8.5, which limits its understanding of C++ to C++11. Would it be possible to at least target the headers of GCC5? That would at least support C++14. Of course, with GCC8.2.0 being available as well, C++17 should also be possible ;)
Kind regards,
Philipp
_______________________________________________ claix18-slurm-pilot mailing list -- claix18-slurm-pilot@lists.rwth-aachen.de To unsubscribe send an email to claix18-slurm-pilot-leave@lists.rwth-aachen.de
-- Marcus Wagner, Dipl.-Inf.
IT Center Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24383 Fax: +49 241 80-624383 wagner@itc.rwth-aachen.de www.itc.rwth-aachen.de
_______________________________________________ claix18-slurm-pilot mailing list -- claix18-slurm-pilot@lists.rwth-aachen.de To unsubscribe send an email to claix18-slurm-pilot-leave@lists.rwth-aachen.de
-- Philipp Berger https://moves.rwth-aachen.de/people/berger/ Software Modeling and Verification Group RWTH Aachen University Phone +49/241/80-21206 Ahornstraße 55, 52056 Aachen, Germany
Hi all, so let me give a more complete view on the current situation: 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. 2) Our custom-built GCC modules (the latest being GCC 8.2.0) come with their corresponding versions of libstdc++, including support for newer C++ standards. 3) For Clang we want to enable using newer C++ standards, but having a dependency on a newer GCC causes all kinds of problems (What if we update GCC, do we need to rebuild Clang? Are there compatibility issues between Clang and libstdc++? What happens if a user loads a different GCC than we envisioned to be used with that particular version of Clang?) So we currently build and install a matching version of libc++ (LLVM's C++ library) and tell Clang to use its headers and shared library by default. 4) The Intel Compiler just uses whatever libstdc++ it can find. By default this will be the one from GCC 4.8.5, but by loading a newer GCC before the intel module you can use a more recent version (as Paul described last week). So based on 3) I can successfully compile the std::optional example from https://en.cppreference.com/w/cpp/utility/optional (from a fresh environment with the default modules in each case): # module switch intel clang # $CXX -std=c++17 optional.cpp 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). 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) 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. Kind regards, Jonas
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
(without being able to test it - I'm not an C++ guy, and google's example cases does not do not have an issue with old headerz) Try this: $ module purge; module load DEVELOP gcc/8 ; module load clang ; module load intelmpi This will load Glang after gcc/8 making the headers of latter available fo the Clang compiler. Do NOT 'just load gcc/8' as this would lead to wrong environment. Note that IIRC the Intel compiler have the same issue with later C++ standards (also Intel compiler rely on system headers). Years ago the same state was with c++11 standard... On 01/31/2019 10:21 AM, Marcus Wagner wrote:
Paul, could you have a look?
Best Marcus
On 1/25/19 1:42 PM, Philipp Berger wrote:
Dear list,
apparently the Clang installation is build against the headers of the default GCC 4.8.5, which limits its understanding of C++ to C++11. Would it be possible to at least target the headers of GCC5? That would at least support C++14. Of course, with GCC8.2.0 being available as well, C++17 should also be possible ;)
Kind regards,
Philipp
_______________________________________________ claix18-slurm-pilot mailing list -- claix18-slurm-pilot@lists.rwth-aachen.de To unsubscribe send an email to claix18-slurm-pilot-leave@lists.rwth-aachen.de
-- Marcus Wagner, Dipl.-Inf.
IT Center Abteilung: Systeme und Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24383 Fax: +49 241 80-624383 wagner@itc.rwth-aachen.de www.itc.rwth-aachen.de
-- Dipl.-Inform. Paul Kapinos - High Performance Computing, RWTH Aachen University, IT Center Seffenter Weg 23, D 52074 Aachen (Germany) Tel: +49 241/80-24915
participants (4)
-
Hahnfeld, Jonas -
Marcus Wagner -
Paul Kapinos -
Philipp Berger