Repository navigation
python-gssapi incompatible With Cython 3.1 #359
Description
With the release of Cython, the installment of python-gssapi broke on Linux systems:
building 'gssapi.raw.misc' extension
creating build/temp.linux-x86_64-cpython-38/gssapi/raw
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -I/opt/rh/rh-python38/root/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -I/opt/rh/rh-python38/root/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Igssapi/raw -I/opt/rh/rh-python38/root/usr/include/python3.8 -c gssapi/raw/misc.c -o build/temp.linux-x86_64-cpython-38/gssapi/raw/misc.o -DHAS_GSSAPI_EXT_H
gssapi/raw/misc.c: In function ‘__pyx_pw_6gssapi_3raw_4misc_3inquire_names_for_mech’:
gssapi/raw/misc.c:3284:7: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (Py_ssize_t i = __pyx_nargs; i < 1; i++) {
According to Cython devs, Cython 3.1+ requires C99 compatible C compiler:
cython/cython#6861 (comment)
Activity
jborean93 commentedon May 26, 2025
Can you not use a C99 compatible C compiler? Is it not enabled by default in modern distros?
If not you can disable build isolation or use the
PIP_CONSTRAINTSenv var to constrain the Cython to the version needed.MaicoTimmerman commentedon May 27, 2025
In modern distros, yes. In our case we ran into the problem on older machines on CentOS 7, which comes with GCC 4.8.5 and uses C89/C90 by default. Build constraints help, I did not think about those and most build frontends support something like that. UV has
--build-constraint, Pex uses pip, but Hatch doesn't.Disabling build isolation is not really an option, as it would require all dependencies to have compatible build systems.
The main problem here is that a new version of Cython 3.1.0 available on Pypi broke builds. python-gssapi has to compile against Kerberos libraries, thus it cannot use wheels. However, it is not version bounding (or even better pinning) it's
build-system, resulting in not have deterministic builds/installs. Any new release ofCythonorsetuptoolscan break installs.IMO it would be best to pin the
build-systemdependencies, in order to guarantee deterministic builds for users.jborean93 commentedon May 28, 2025
In the past this package shipped the actual cythonised .c files to avoid needing Cython when building the project. This predated PEP 517 which made it harder to guarantee that build requirements would be available. It ended up moving away and just having a version range of Cython mostly to ensure that new Python versions could work out of the box without requiring a new release of this project just with a bumped build dependency.
Now we can definitely revisit this as deterministic builds is certainly a nice goal but as you've encountered the build is also affected by the end user's system so building might change over time based on the gcc version. What is probably ideal for your use case here is to pre-compile a wheel for your host so that you don't need to compile this everytime you install the package. The benefits here are:
I'm going on leave and will mostly be away for a few weeks but my gut is that #360 is not the right way to go about this. We should either keep things they way they are and recommend people pin/constrain their build deps/look at pre-building wheels, or look at pinning to a specific version. I'll have to think it through and see whether pinning a version outweighs the disadvantages here.