Power9 build fails with system compiler and -mcpu=native (default)

[Flamefire]

I'm trying to build the Java-1.8 EC on Power9 and the configure process aborts. I tracked that to the following:

/usr/bin/gcc -mcpu=native /tmp/conftest.c
cc1: error: unrecognized argument in option '-mcpu=power9'
cc1: note: valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8 powerpc powerpc64 powerpc64le rs64 titan

I have no idea, why "native" is mapped to a (non-existing) "power9", but it seems the system compiler cannot reliably be used.

This is the first package where I encountered this issue, no idea why others didn't fail before. E.g. AFAIK GCC itself is built with the system compiler first.

The version is

gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

[Flamefire]

Oh, seems to be caused by some stray CFLAGS set in the current environment which are not overwritten (sometimes?)

[boegel]

@Flamefire When system is used as compiler, EasyBuild doesn't set up the build environment at all, other than loading modules for dependencies. It doesn't (re)set $CFLAGS & co, so if there was a value set outside of eb, it may cause trouble.

[Flamefire]

Ok, this is unexpected for me at least.

[boegel]

@Flamefire Defining $CC, $CFLAGS & co would require checking the system compiler thoroughly, which we don't right now. And it raises the question whether just checking gcc & g++ is enough (maybe cc and c++ are different...).

Another option is to unset $CC, $CFLAGS & co (along with a big fat warning) if they are set outside of EasyBuild, and not defining by EasyBuild itself because the system toolchain is used?

[Flamefire]

Is there any other way to specify optimizations for system toolchain built ECs? If not, I'd go for a info of the kind: Building with system toolchain, using <list of flags and their values detected to be set in env> from current environment> This would have helped me in this case because my log showed a strange error message (blame the buggy compiler for the strangeness) and it took me a while to figure out where the CFLAGS came from. Having some output similar to the "setting CFLAGS=" (for non-system TC) before the actual build in the log would have helped.

[boegel]

@Flamefire Right now, no. EasyBuild doesn't take any action w.r.t. controlling the build environment when the system toolchain is used, other than loading the modules for the dependencies (unless the easyconfig or easyblocks being used to something specific, of course).

[Flamefire]

Ok, and what about a log entry about those common vars? Just a single info line for all vars