GeezerVison is showing github.com — On macOS, Configure script assumes that "gcc" is an alias for "clang", even if it really is GCC · Issue #96249 · python/cpython
On macOS, Configure script assumes that "gcc" is an alias for "clang", even if it really is GCC #96249DescriptionYour environment
Bug report
Apologies if this is a known "wontfix" issue, I didn't see it mentioned in a search of past issues.
The configure.ac script assumes that gcc is actually clang on MacOS and uses Clang's -fprofile-instr-generate flag for PGO instead of GCC's -fprofile-generate, leading to build failure when PGO is turned on.
Steps to reproduce on MacOS:
sudo port install gcc
# or `brew install gcc`, same result
CC='/opt/local/bin/gcc-mp-12' pyenv install --verbose 3.10.6
Outcome:
...
gcc-mp-12: error: unrecognized command-line option '-fprofile-instr-generate'; did you mean '-fprofile-generate'?
...
The problem is found here: https://github.com/python/cpython/blob/3.10/configure.ac#L1491-L1514
case $CC in
*clang*)
# Any changes made here should be reflected in the GCC+Darwin case below
...
;;
*gcc*)
case $ac_sys_system in
Darwin*)
PGO_PROF_GEN_FLAG="-fprofile-instr-generate"
PGO_PROF_USE_FLAG="-fprofile-instr-use=code.profclangd"
MacOS (perhaps annoyingly) ships with gcc as an alias for clang, so the configure script sensibly assumes that gcc is actually clang and sets its options accordingly.
However, that isn't always a correct assumption!
Possible solutions:
- Check for the presence of
Apple clang in the $CC --version output.
- Check that the absolute path of
$CC is /usr/bin/gcc.
Activitygwerbin commented on Aug 24, 2022 Here's a rudimentary patch that should hopefully fix this particular issue, although I don't know if there will be other problems downstream of this one:
--- configure.ac 2022-08-01 16:25:27.000000000 -0400
+++ configure.ac 2022-08-24 16:44:31.000000000 -0400
@@ -1420,7 +1420,7 @@
;;
esac
;;
- *gcc*)
+ /usr/bin/gcc)
case $ac_sys_system in
Darwin*)
LTOFLAGS="-flto -Wl,-export_dynamic"
@@ -1431,6 +1431,9 @@
;;
esac
;;
+ *gcc*)
+ LTOFLAGS="-flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none"
+ ;;
esac
if test "$ac_cv_prog_cc_g" = "yes"
@@ -1488,7 +1491,7 @@
fi
fi
;;
- *gcc*)
+ /usr/bin/gcc)
case $ac_sys_system in
Darwin*)
PGO_PROF_GEN_FLAG="-fprofile-instr-generate"
@@ -1499,9 +1502,9 @@
then
LLVM_PROF_ERR=yes
if test "${REQUIRE_PGO}" = "yes"
- then
- AC_MSG_ERROR([llvm-profdata is required for a --enable-optimizations build but could not be found.])
- fi
+ then
+ AC_MSG_ERROR([llvm-profdata is required for a --enable-optimizations build but could not be found.])
+ fi
fi
;;
*)
@@ -1512,6 +1515,12 @@
;;
esac
;;
+ *gcc*)
+ PGO_PROF_GEN_FLAG="-fprofile-generate"
+ PGO_PROF_USE_FLAG="-fprofile-use -fprofile-correction"
+ LLVM_PROF_MERGER="true"
+ LLVM_PROF_FILE=""
+ ;;
*icc*)
PGO_PROF_GEN_FLAG="-prof-gen"
PGO_PROF_USE_FLAG="-prof-use"ned-deily commented on Aug 24, 2022 Thanks for the report. There are other places in configure.ac where there are or should be these kinds of tests. I think we should bite the bullet and fix them comprehensively including making clang the CC default on macOS. changed the title [-]On MacOS, Configure script assumes that "gcc" is an alias for "clang", even if it really is GCC[/-] [+]On macOS, Configure script assumes that "gcc" is an alias for "clang", even if it really is GCC[/+] on Aug 24, 2022tiran commented on Aug 25, 2022 FWIW 3.11 has a new ac_cv_cc_name variable in configure. We could replace our heuristics with the variable. Reacted by Michael Droettboom, Zachary Ware and Erlend E. Aasland mdboom commented on Aug 25, 2022
FWIW 3.11 has a new ac_cv_cc_name variable in configure. We could replace our heuristics with the variable.
Note to self, should probably update #94760 to use this approach as well. Reacted by Erlend E. Aasland
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|