configure.ac: using $CC to check compiler names may result in erroneous judgements #96398
Comments
|
We are aware that the checks are problematic have already plans to replace |
|
cc. @corona10 |
|
A quick summary: #110034 points out that we've got various attempts to detect the compiler version in configure. There's the #110577 points out that the compiler selection check on macOS is at least partly obsolete. Perhaps that issue deserves to be re-opened and investigated on its own.
|
|
#117815 adapts most relevant checks to use |
- emcc defines __EMSCRIPTEN__ - mpicc doesn't define anything in particular; detect it using basename
Introduce a cached variable $ac_cv_gcc_compat and set it to 'yes' if the C preprocessor defines the __GNUC__ macro.
Introduce a cached variable $ac_cv_gcc_compat and set it to 'yes' if the C preprocessor defines the __GNUC__ macro.
Introduce a cached variable $ac_cv_gcc_compat and set it to 'yes' if the C preprocessor defines the __GNUC__ macro.
See pythongh-113632 and python/peps#3612: Emscripten is no longer supported
…ython#117819) - emcc defines __EMSCRIPTEN__ - mpicc doesn't define anything in particular; detect it using basename
…117825) Introduce a cached variable $ac_cv_gcc_compat and set it to 'yes' if the C preprocessor defines the __GNUC__ macro.
The following variables are now used in compiler checks: - $ac_cv_gcc_compat is set to 'yes' for GCC compatible compilers (the C preprocessor defines the __GNUC__ macro) - for compiler basename checks, use $CC_BASENAME (may contain platform triplets) - for the rest, use $ac_cv_cc_name (does not contain platform triplets)
|
This should now be resolved. Please shout out if you still encounter problems. |
…ython#117815) The following variables are now used in compiler checks: - $ac_cv_gcc_compat is set to 'yes' for GCC compatible compilers (the C preprocessor defines the __GNUC__ macro) - for compiler basename checks, use $CC_BASENAME (may contain platform triplets) - for the rest, use $ac_cv_cc_name (does not contain platform triplets)
configure.ac contains multiple checks of this kind:
When paths contain "clang"/"gcc"/"icc", they might be part of $CC
for example because of the "--sysroot" parameter. That could cause
judgement error about clang/gcc/icc compilers. e.g.
when "icc" is containded in working path, below errors are reported when compiling python3:
x86_64-wrs-linux-gcc: error: strict: No such file or directory
x86_64-wrs-linux-gcc: error: unrecognized command line option '-fp-model'
Linked PRs
The text was updated successfully, but these errors were encountered: