Hello,

due to bugs in the GCC SH backend [1], I had to build the python3.13 package on sh4
with a patched version of gcc-snapshot (version 1:20241004-1+sh4.2).

Surprinsingly, this resulted in the build compiler "gcc-15" being stored into the
Python configuration of the python3.13 so that some Python packages now FTBFS on
sh4 with [3]:

creating build/temp.linux-sh4-cpython-313
gcc-15 -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O2 -Wall -g -O2 -Werror=implicit-function-declaration \
-ffile-prefix-map=/<<PKGBUILDDIR>>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat \
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 \
-fPIC -I/usr/include/python3.13 -I/usr/include -c lxc.c -o build/temp.linux-sh4-cpython-313/lxc.o
error: command 'gcc-15' failed: No such file or directory
E: pybuild pybuild:389: build: plugin distutils failed with: exit code=1: /usr/bin/python3.13 setup.py build
I: pybuild base:311: /usr/bin/python3 setup.py build

Since I'm not sure whether this intentional or not (I would expect the Python configuration
to store the name of the compiler with the help of the target triplet and not the versioned
compiler binary), I'm reporting this issue here.

At first sight, I have not seen where this information is actually stored in src:python3.13.

Thanks,
Adrian

Attaching a tarball with the collected _sysconfigdata* from the build directory.

Thanks,
Adrian

Hi John (2024.11.15_08:35:24_-0400)

...

That is intentional. Python upstream does this to ensure that C
extensions are built with a compatible compiler.

Obviously, it didn't result in the right behaviour here. But I don't
think this is necessarily something we want to patch.

Stefano