-
Notifications
You must be signed in to change notification settings - Fork 29
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
Segmentation fault when running tests in python-3.10 with 0.7.a2 and 0.7.0a3, 0.6.0 is fine #165
Comments
That's worrying. I can't reproduce this on MacOS. I don't immediately have Linux available to test: $ pip install python-flint==0.7.0a3
...
$ python -m flint.test
...
----------------------------------------
OK: Your installation of python-flint seems to be working just fine!
----------------------------------------
I wonder if we are building the libraries for generic x86_64 correctly: python-flint/bin/build_dependencies_unix.sh Lines 280 to 291 in 71e4800
Maybe that needs python-flint/bin/cibw_before_all_linux.sh Lines 3 to 7 in 71e4800
What does Flint's |
This is in the
https://github.com/flintlib/python-flint/actions/runs/9866479989/job/27246112789 We need to prevent Flint from detecting the CPU in the build machine. It also looks like we should set the Is there something about this that has changed in recent Flint versions e.g. 3.1.0 or something? I haven't seen any problems with python-flint 0.6.0 which is built using Flint 3.0.1. Now with a greater understanding of Flint's build configuration I can see what all of this is doing. Full log:
|
Edgar can you try downloading the Ubuntu wheels artefact from the bottom of the actions page here: |
Actually maybe setting
|
What is the correct way to build Flint if the intention is to distribute a generic x86_64 binary? |
I've attached three different zip files containing manylinux x86-64 wheels for CPython 3.10. I don't have an x86-64 system available to test right now. Can you test installing each of these wheels to see if any work: wheel_flint_3.0.1.zip You should be able to just I think that maybe something has changed in Flint 3.1 that means that our CI wheel build no longer produces generic x86-64 binaries on Linux. We will need to find a way to build generic binaries with Flint 3.1 or otherwise drop back to shipping Flint 3.0.1 in the PyPI wheels. Previous releases of python-flint have used Flint |
For the record, this is how I enabled generic bottle for flint in homebrew: |
I will try to build my own wheels on a vm, and see if I can tweak it to make it work |
The wheels I showed above are all built in the CI here. If you open a pull request then you can download the wheels from the GitHub Actions artifacts. That's the best way to test because that is also how the wheels are made for deployment to PyPI. |
I've bumped the version in 0.7.0a4 ready to push a new release to PyPI. Once we can test that installing from PyPI works we can close this. |
The 0.7.0a4 release is on pypi now so hopefully this is fixed. We will need to remember when Flint 3.2 comes around to change the build flags (remove --enable-arch). We can close this once you confirm that installing from pypi works |
it all works fine |
ps: the |
Thanks Edgar for reporting and testing/fixing this. The number one thing that worries me with python-flint is that it might fail on other people's computers and that I won't have access to the hardware to test it. I tried to make checks comprehensive in CI but something like this appears to pass in CI even though it will fail for actual users. |
I understand; yeah, testing on old hardware is hard. Luckily, I have plenty of that around. |
Here is an edited log.
I couldn't try 0.7.a1, as it fails to find a wheel, and to build, as expected.
The text was updated successfully, but these errors were encountered: