cysignals
cysignals copied to clipboard
sagemath
Replace compile-time dependency on pari by run-time dispatch
The current design is not compatible with modern Python packaging, in which PEP517/518 dictate that there is no such thing as an "optional build dependency". Also, if installing a wheel one can never be sure whether it has been built with the PARI connection or not.
This should be replaced by a hook into which PARI (via cypari/cypari2) can install itself.
I was thinking about this just yesterday. I admit I don't 100% understand how the PARI integration is supposed to work or what it's for. But AFAICT it could be replaced with a more generic hook. Such a hook might be useful for other interfaces as well, such as for GAP.
If nothing else, for easier pip-install, --without-pari should be the default, rather than --with-pari.
Let's look into creating the hook sometime during in the Sage 9.4 development cycle.
I'm able to build wheels (for manylinux and macOS) for a cython module dependent on an external C++ library in https://github.com/dimpase/primecountpy using https://github.com/pypa/cibuildwheel
OK, here we'd need to build libpari - should not make a difference.
Should I try?
If I recall correctly, one reason Pari gets in here is that its threads implementation is a bit funny, and if it's not called early things go bad, one gets some weird TLS-related segfaults. (But maybe it's my PTSD speaks up :-))
Anyhow, we just got a wheel builder in here, Pari or no Pari (the wheels we build do have Pari linked in).
If I recall correctly, one reason Pari gets in here is that its threads implementation is a bit funny, and if it's not called early things go bad, one gets some weird TLS-related segfaults. (But maybe it's my PTSD speaks up :-))
#149 removes exactly this dependency. Pari headers provide PARI_SIGINT_block and PARI_SIGINT_pending. This is all we need. What we aim for is somehow getting this stuff on runtime, if available.
I don't know if this is even possible and less so, if it is possible to integrate such a mechanism in cysignals. I do have a workaround by just passing pointers on runtime. #149 can get those pointers, provided that cypari2 has https://github.com/sagemath/cypari2/pull/109 merged.
On Wed, 1 Dec 2021, 19:35 Jonathan Kliem, @.***> wrote:
If I recall correctly, one reason Pari gets in here is that its threads implementation is a bit funny, and if it's not called early things go bad, one gets some weird TLS-related segfaults. (But maybe it's my PTSD speaks up :-))
#149 https://github.com/sagemath/cysignals/pull/149 removes exactly this dependency. Pari headers provide PARI_SIGINT_block and PARI_SIGINT_pending. This is all we need. What we aim for is somehow getting this stuff on runtime, if available.
I don't know if this is even possible and less so, if it is possible to integrate such a mechanism in cysignals. I do have a workaround by just passing pointers on runtime. #149 https://github.com/sagemath/cysignals/pull/149 can get those pointers, provided that cypari2 has sagemath/cypari2#109 https://github.com/sagemath/cypari2/pull/109 merged.
we can certainly merge the latter and see if all this plays together well.
I believe that in the linux multithreaded setting Pari has to be "served first", and this was accomplished by the hack you are removing here.
—
You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/sagemath/cysignals/issues/125#issuecomment-983989751, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJXYHFS5PFH5IKR3NQ4PV3UOZ2HTANCNFSM4X7GMOVA .