linux x86_64 builds contain references to `clang` -- aarch64 does not

[asottile-sentry]

compare:

wget https://github.com/indygreg/python-build-standalone/releases/download/20240107/cpython-3.12.1+20240107-x86_64-unknown-linux-gnu-pgo+lto-full.tar.zst
wget https://github.com/indygreg/python-build-standalone/releases/download/20240107/cpython-3.12.1+20240107-aarch64-unknown-linux-gnu-lto-full.tar.zst
mkdir x64 arm64
tar -C x64 -xf cpython-3.12.1+20240107-x86_64-unknown-linux-gnu-pgo+lto-full.tar.zst
tar -C arm64 -xf cpython-3.12.1+20240107-aarch64-unknown-linux-gnu-lto-full.tar.zst

$ grep clang arm64/python/install/lib/python3.12/_sysconfigdata_*
$ grep clang x64/python/install/lib/python3.12/_sysconfigdata_*
 'BLDSHARED': 'clang -pthread -shared  -Wl,--exclude-libs,ALL '
 'CC': 'clang -pthread',
                "'host_alias=x86_64-unknown-linux-gnu' 'CC=clang' 'CFLAGS= "
 'CXX': 'clang++ -pthread',
 'LDCXXSHARED': 'clang++ -pthread -shared',
 'LDSHARED': 'clang -pthread -shared  -Wl,--exclude-libs,ALL '
                    '-fprofile-instr-use=code.profclangd -I./Include/internal '
                   '-fprofile-instr-use=code.profclangd -I./Include/internal '
                    '-fprofile-instr-use=code.profclangd -I./Include/internal '
 'LINKCC': 'clang -pthread -fno-pie -no-pie',
 'LLVM_PROF_FILE': 'LLVM_PROFILE_FILE="code-%p.profclangr"',
                     '-output=code.profclangd *.profclangr',
 'PGO_PROF_USE_FLAG': '-fprofile-instr-use=code.profclangd',
                             '-fprofile-instr-use=code.profclangd '
                     '-fvisibility=hidden -fprofile-instr-use=code.profclangd '
                   '-fprofile-instr-use=code.profclangd -I./Include/internal '
                        '-fprofile-instr-use=code.profclangd 

seems the fixes for #194 didn't really stick here?

[indygreg]

The aarch64 builds are cross-compiled using gcc, not clang.

And so far the only sysconfig rewriting we do is stripping -fdebug-default-version=4 and some -I compiler flags: we don't attempt to rewrite clang to gcc.

It is tempting to rewrite clang to gcc - at least in some cases - to maintain compatibility with other build environments which only have gcc. But we need to be careful since some command argument fragments would be invalid on GCC.

[bluss]

I wrote something just to patch the install directory -- https://github.com/bluss/sysconfigpatcher I'm not sure it helps much, but it can solve some problems. How to make sense of all the build variables in the sysconf is beyond me, not sure how python packages in general could ever make use of them - except I've seen that they use CC, so I tried to patch it (to cc which seems like a quaint old linuxism).

That script is also totally a hack, but maybe it could be incrementally improved into working in most situations.

[geofft]

This is also one of the things that uv patches post extraction (using https://github.com/astral-sh/uv/blob/0.5.25/crates/uv-python/src/sysconfig/mod.rs , which is based on sysconfigpatcher mentioned above). Given that uv is relying on doing this rewrite, I think we'd effectively treat it as a bug if that rewrite did not work and so we might as well attempt to move it into python-build-standalone.