Skip to content

python-gssapi incompatible With Cython 3.1 #359

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MaicoTimmerman opened this issue May 26, 2025 · 3 comments · May be fixed by #360
Open

python-gssapi incompatible With Cython 3.1 #359

MaicoTimmerman opened this issue May 26, 2025 · 3 comments · May be fixed by #360

Comments

@MaicoTimmerman
Copy link

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)

@jborean93
Copy link
Contributor

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_CONSTRAINTS env var to constrain the Cython to the version needed.

@MaicoTimmerman
Copy link
Author

MaicoTimmerman commented 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 of Cython or setuptools can break installs.

IMO it would be best to pin the build-system dependencies, in order to guarantee deterministic builds for users.

@jborean93
Copy link
Contributor

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:

  • you aren't subject to build requirement changes over time, basically when you decide to rebuild the wheel
  • installing is a lot quicker, no need to compile the code anymore
  • you don't need any dev headers during the install, only when creating the wheel for the first time

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants