installation of GCCcore/6.4.0 fails on CentOS 8.2

[boegel]

I'm mostly opening this for reference, not sure if we want to go through the trouble of fixing it...

recommended isl version is 0.16 or 0.15, the minimum required isl version 0.14 is deprecated
checking for isl 0.16 or 0.15... no
*** This configuration is not supported in the following subdirectories:
     gnattools gotools target-libada target-libgo target-libffi target-zlib target-libjava target-libobjc target-liboffloadmic target-boehm-gc
    (Any other directories should still work fine.)
/tmp/eb-j2xgtx4w/eb-jki7lu51/ccsxayaS.s: Assembler messages:
/tmp/eb-j2xgtx4w/eb-jki7lu51/ccsxayaS.s:11: Error: unknown .loc sub-directive `view'
/tmp/eb-j2xgtx4w/eb-jki7lu51/ccsxayaS.s:11: Error: junk at end of line, first unrecognized character is `-'
/tmp/eb-j2xgtx4w/eb-jki7lu51/ccsxayaS.s:13: Error: unknown .loc sub-directive `view'
/tmp/eb-j2xgtx4w/eb-jki7lu51/ccsxayaS.s:13: Error: unknown pseudo-op: `.lvu1'
/tmp/eb-j2xgtx4w/eb-jki7lu51/ccsxayaS.s:14: Error: unknown .loc sub-directive `view'
/tmp/eb-j2xgtx4w/eb-jki7lu51/ccsxayaS.s:14: Error: unknown pseudo-op: `.lvu2'
*** The command 'gcc -o conftest -g -O2   conftest.c' failed.
*** You must set the environment variable CC to a working compiler.

Likely culprit is the recent system GCC in CentOS 8.2:

[easybuilder@generoso ~]$ gcc --version
gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)

[oxford-arcteam]

We have encountered this recently on our new CentOS 8.2 cluster. We are currently setting up a test EasyBuild environment and were attempting to build Gaussian 16 with PGI 16.7 this depends on GCC 5,4.0 which fails. I presume this would also be an issue for earlier Intel toolchains which depend on these older GCC versions.

[boegel]

@oxford-arc Indeed, using toolchains based on older GCC versions on CentOS 8 is bound to lead to problems...

Based on our testing on CentOS 8 so far:

• foss/2018b (based on GCC 7.3.0) is mostly OK, intel/2018b is not (due to problems with the Intel compilers themselves)
• foss/2019a + intel/2019a (based on GCC 8.2.0), foss/2019b + intel/2019b (based on GCC 8.3.0) and foss/2020a+ intel/2020a (based on GCC 9.3.0) work fine

[edmondac]

@oxford-arc Indeed, using toolchains based on older GCC versions on CentOS 8 is bound to lead to problems...

Based on our testing on CentOS 8 so far:

* `foss/2018b` (based on GCC 7.3.0) is mostly OK, `intel/2018b` is not (due to problems with the Intel compilers themselves)

* `foss/2019a` + `intel/2019a` (based on GCC 8.2.0), `foss/2019b` + `intel/2019b` (based on GCC 8.3.0) and `foss/2020a`+ `intel/2020a` (based on GCC 9.3.0) work fine

That agrees with what we've been seeing too

[stevenvdb]

I ran into the same problem when installing GCCcore/6.4.0 on Rocky 8.7. The problem seems to be an incompatibility of the assembler from binutils and the system gcc. The solution is to use a newer binutils version (for instance 2.32) as a build dependency for GCCcore/6.4.0. If I understand things correctly, this should not have a big effect on the rest of the toolchain, since this binutils build dependency is only used for bootstrapping, and a toolchain-specific binutils module is built later on.

I also had to apply the patch https://reviews.llvm.org/rG383fe5c8668f63ef21c646b43f48da9fa41aa100 Afterwards I was able to install both foss/2018a and intel/2018a on Rocky 8.7 (the latter toolchain giving a lot more headaches). I am not sure if there is any interest to get those changes into EasyBuild, since these toolchains are already marked as deprecated.

[Micket]

We have had many issues like this, and it's always the case that binutils must never be older than the OS binutils. Old toolchains should just no longer be used, and if someone insists, they have to tweak the binutils used, to ensure the EB ones are newer then the OS, or filter them out.

Don't think there is anything to saw or do in with this issue (even more so given that the centos is dead and GCCcore/6.4.0 is well deprecated))