Closed mkoeppe closed 3 months ago
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?
No, the best way forward is to merge #149
Doesn't #149 need newer Cython?
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 :-))
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 .
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.