Description

sorcio

opened on Oct 9, 2023

Issue body actions

Bug report

Bug description:

configure.ac has some special handling for detecting the default compiler on Apple platforms. Currently the script will check for both "gcc" and "clang". If both are defined, it only selects clang in case gcc is actually llvm-gcc.

cpython/configure.ac

Lines 819 to 823 in ea7b53f

	if test -n "$found_gcc" -a -n "$found_clang"
	then
	if test -n "`"$found_gcc" --version | grep llvm-gcc`"
	then
	AC_MSG_NOTICE([Detected llvm-gcc, falling back to clang])

llvm-gcc and hasn't been distributed by Apple since Xcode 5 (2013), so the test will be false in basically all cases (all supported cases?). After this, the decision to set CC is delegated to AC_PROG_CC, which will use "gcc" by default.

If no gcc installed, "gcc" is just an alias to clang, and since clang is now fully supported, this will usually compile just fine. The issue is that the configure script itself will inspect CC (e.g. to apply some flags). Sometimes these checks have an additional guard like cc_is_clang or ac_sys_system = "Darwin" but sometimes they don't. E.g. recently I saw warnings about a redundant -fno-semantic-interposition being set.

My very opinionated opinion is that the default CC should always be clang on Apple platforms, just like in the Mac build script. And that some of these CC checks might need to be reviewed. E.g. use cc_is_clang whenever is possible, or abstract the actual compiler in a different variable, or possibly—going forward—forget entirely about the "gcc is actually clang" case.

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Activity

1. sorcio

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Oct 9, 2023
2. ned-deily

   added

   OS-mac

   buildThe build process and cross-buildThe build process and cross-build

   on Oct 9, 2023
3. sorcio commented on Oct 13, 2023

   

   sorcio

   on Oct 13, 2023

   ContributorAuthor

   More actions

   I'm leaving some open questions / notes, anyone feel free to provide input.

   1. When should configure prefer gcc over clang?

   When both are in PATH, and no CC was specified, I'm presuming that 3.13+ builds always prefer clang. This changes default behavior. Impact:

   • Local builds: will switch from gcc (which usually is an alias to clang) to clang, some build configuration might change
   • macOS CI: currently uses clang through the "gcc" alias, some build configuration might change
   • macOS buildbots: same as above
   • build-installer.py: not impacted (clang for deployment target 10.9+, gcc otherwise)
   • Pyenv: not impacted (clang for deployment target 10.10+)
   • Homebrew: not impacted (defaults to Apple clang)

   Options to consider:

   • prefer GCC if actual GCC is in PATH (i.e. gcc --version contains "Free Software Foundation"), so it doesn't confuse setups that prefer GNU toolchain
   • only switch to clang if gcc --version contains "clang"
   • ...or if it contains "Apple clang" (this minimizes impact on custom setups)
   • decide based on some more complicated version check
   • just use cc

   2. Is it ok to remove old cruft?

   I'm talking only about stuff like special-casing around older versions of gcc (on Darwin) which are not relevant anymore because they don't have C11 support. Older Mac OS X / macOS versions and older SDKs will be left unchanged, although I suspect CPython 3.13 won't build without some effort.

   The idea is that configure.ac is not the place for historical documentation of weird platform behavior that is not supported anymore, because every check adds runtime and it's a discouraging nightmare to maintain.

   3. What about other Darwin systems?

   E.g. PEP 730 wishes to promote iOS to an officially supported platform. Anything suggested here that would conflict with that goal? I'd guess not, as it's just changing a default, but it's better to be sure. Any other Darwins that I'm not accounting for?

   4. What about cross-compilation?

   I've never touched cross-compilation on/for Darwin, I have no idea here.

   5. What about clang on non-Darwin platforms?

   Yeah, what about it? It's not the point of this issue. But maybe we should pay attention to how clang is configured by default in general, not just on Darwin.
4. sorcio commented on Oct 13, 2023

   

   sorcio

   on Oct 13, 2023

   ContributorAuthor

   More actions

   Regarding question 1 (when to prefer gcc) it might be relevant that PEP 11 doesn't list gcc as a supported compiler on Darwin, making a stronger case for never selecting gcc unless it's the only detected compiler (weird setup but ok), or it's explicitly set as CC.
5. erlend-aasland commented on Apr 12, 2024

   

   erlend-aasland

   on Apr 12, 2024 · Hidden as off-topic

   show commentMore actions
6. erlend-aasland

   closed this as not plannedon Apr 12, 2024
7. erlend-aasland

   reopened this on Apr 12, 2024
8. erezgeva commented on Feb 13, 2026

   

   erezgeva

   on Feb 13, 2026

   More actions

   Sorry for the interference.

   configure.ac uses GNU autoconf, the defaults are
   CC=cc and CXX=g++.

   However some POSIX based projects uses CC=gcc by default.

   What Apple did is to link /usr/bin/cc, /usr/bin/gcc and /usr/bin/g++ to Clang.
   And leave autoconf with its own defaults.

   See Apple documentation on GNU Autoconf:
   https://developer.apple.com/library/archive/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html

   As Clang is to the most backward compatible with GCC, this arraignment works with many POSIX based projects.
9. hugovk

   closed this as a duplicateof configure.ac: using $CC to check compiler names may result in erroneous judgements #96398 on Oct 29, 2026

Issue actions