-
Notifications
You must be signed in to change notification settings - Fork 526
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
wxPython fails to build on free threaded python 3.13t due to __pyx_vectorcallfunc related error in nanosvg-extension (from source, no wheel available) #2707
Comments
It might (would) be solved if the .c file wasn't committed, and let a modern build backend build from source, as the pyx file would be used. Committing a .c isn't recommended by cython now with the python build improvements, where not having cython already installed isn't an issue anymore, as it can be specified as a build-time requirement in pyproject.toml. All that is assuming the issue is already solved in a recent Cython release. |
I am not very familiar with cython and building from source. Where do I need to specifiy language_level=3 in the files or command line? |
For cython version: Lines 72 to 78 in 5a13d13
For the Cython config: Lines 50 to 54 in 5a13d13
File to delete to make sure it gets recreated: https://github.com/wxWidgets/Phoenix/blob/5a13d13c316c0e396355d648ec910e9c3934886d/wx/svg/_nanosvg.c Since you're on Windows, the CI workflows can build you a wheel. You'd also need to add the free threaded version to the Python versions to build wheels for: Add Phoenix/.github/workflows/ci-build.yml Line 108 in 5a13d13
With these changes, you'd get a new wheel in about 45 minutes |
Took me a while but I managed to create a branch with the modified files and deleted _nanosvg.c, with that branch I can now do a PR against the fork as you said. |
Great!
In a PR, just like here, it won't happen. Unless you specifically added some pypi authentication token that happen to be valid to push to wxPython (which only like two people are allowed), the upload step would fail when merging to your fork. It fails on mine. It also won't create a release, on your fork, unless you manually do so (not by actions). It also can't make a new file to the wxPython downloads (snapshot), unless you have added secrets called "RIOBU_SSH_KEY" and "RIOBU_KNOWN_HOSTS" that are valid for that upload server, which most probably would never be true. You can take a look at my fork to make sure. Come back if you need more help, or tag me in your PR so I can take a look at the workflow. Depending on your results afterwards, if you have a good experience with the results, we might consider adding support for it here too. (It could be your PR :) ) |
I tried a few things, and discovered some likely blocks (for the workflow):
Comments to the blocksAd 1) Ad 2) Manual buildAlthough I should have known better, I tried to build manually again - with the instructions directly from the repo (Building-wxWidgets. I ran in an venv again, installed setuptools, wheel, six. I run into issue with |
You're totally right, and I'm as surprised as you that setup-python doesn't support free-threaded builds. I quickly did a spot-check before writing my original answer, but as I receive the release notifications of the python-versions repo and I remembered seeing that they had free-threaded builds, and that all these artifacts are available for setup-python, I was surprised that the version file doesn't include them. For a local build, I can suggest to not even try to create the source distribution. Download a recent artifact of an "sdist" (source distribution), that are the same across OSes, and try to build that, like: About some of your issues locally:
|
Well, it should not take very long, as the branch associates appear to be motivated, and merging requires just a few confirmations. For my first manual build I followed the linux build instruction: install setuptools, six, wheel, download and install the wxPython tarball with pip. I skipped the linux packages (python-dev, etc.), and installed cython 3.1.a from repo with the pip install git+https://... . The wheel did build and pip installed the package. Sadly, the interpreter crashed right at the I did not clone the phoenix git recursively, but did so with the submodules. What, if I add --recursive every time? I may try it out. On the other hand, I might have more luck with downloading and building from the sdist artifacts. |
Installing wxPython with pip for python 3.13t fails during generation of the nanosvg extension. Pip build from source because no wheel may be available.
My system: Windows 10 Home 64-bit (10.0, Build 1945)
Python: experimental free threading version Python 3.13t
Environment: created venv, activated manually by navigating to \Scripts and execute batch activate.bat - then stepped out on venv root directory
Packages installed before wxPython (with pip install -U): setuptools, wheel, requests, six, attrdict3
Package Version
attrdict3 2.0.2
certifi 2025.1.31
charset-normalizer 3.4.1
idna 3.10
pip 25.0.1
requests 2.32.3
setuptools 75.8.0
six 1.17.0
urllib3 2.3.0
wheel 0.45.1
The failure happens because
__pyx_vectorcallfunc
is not recognized in CYTHON_METH_FASTCALL function declarations/definitions. For example - line 25916 in file wx\svg\nanosvg:It seems to be recognized within function scope (no error in compiler output, see below), for example: line 23633 to 23649
I have tried the following without success:
The issue must be buried in the free threading architecture - wxPython installs and/or builds from 3.13 successfully.
The relevant compiler error is posted below. I also attached the full redirected stdout as log file.
The text was updated successfully, but these errors were encountered: