Default CC is "gcc" on Mac, but should be "clang"

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

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.

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.

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.

Navigation Menu

Repository navigation

Default CC is "gcc" on Mac, but should be "clang" #110577

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

1. When should `configure` prefer gcc over clang?

2. Is it ok to remove old cruft?

3. What about other Darwin systems?

4. What about cross-compilation?

5. What about clang on non-Darwin platforms?

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	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])

Default CC is "gcc" on Mac, but should be "clang" #110577

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Activity

sorcio commented on Oct 13, 2023

1. When should configure prefer gcc over clang?

2. Is it ok to remove old cruft?

3. What about other Darwin systems?

4. What about cross-compilation?

5. What about clang on non-Darwin platforms?

sorcio commented on Oct 13, 2023

erlend-aasland commented on Apr 12, 2024

erezgeva commented on Feb 13, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

1. When should `configure` prefer gcc over clang?