#11130: Update PARI to version 2.5.0
--------------------------------------------+-------------------------------
Reporter: jdemeyer | Owner: jdemeyer
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-4.7.2
Component: packages | Keywords: pari spkg
Work_issues: | Upstream: N/A
Reviewer: John Cremona, Jeroen Demeyer | Author: Jeroen Demeyer,
John Cremona
Merged: | Dependencies: #11230, #11234,
#11321 (install this '''after''' building PARI)
--------------------------------------------+-------------------------------
Comment(by leif):
Replying to [comment:83 fbissey]:
> Replying to [comment:82 kcrisman]:
> >
> > > Looks as if you're ''somehow^TM^'' mixing the old PARI (at least the
static library `libpari.a`) with the new one; PARI 2.5.0 doesn't have an
`sd_prompt()` function in `default.c` at all.
> >
> > Interestingly, it works fine from scratch (building)! Sorry for the
noise, if noise it was.
> >
> > Is there something about Pari that you shouldn't build it twice in the
same location? I notice that it removes and replaces various things in
`$SAGE_LOCAL` before it's all done, so maybe that could happen.
The PARI spkg doesn't delete anything of previous installs in advance.
(The `.alpha`'''`.p5`''' though had a bug which caused the install script
not to exit with an error if `make` failed. Also, on Cygwin `make -k`
("keep going") was used, but that shouldn't matter here, and has been
removed in the 2.5.0 spkgs.)
> > In principle, one should be able to `./sage -f` a new version, have
something break, and then be able to `./sage -f` the original version and
have everything fine. Or not even HAVE to `./sage -f` the original
version.
Both ''should^TM^'' be possible, at least unless the build succeeds but
the actual installation fails at some point, in which case the former
method should still work.
> > The fact that this doesn't work is not good - shouldn't we only copy
things over/delete things after the build has successfully completed?
That's what we do.
> Well the gp executable is linked against libpari and there is a danger
that the old one will be used when linking if you are not careful enough.
It should be ok in principle but the precaution of removing previous
libpari is a good one.
Things are a little different on Cygwin, since ''the Sage Cygwin
developers'' ;-) copy the DLL also to `$SAGE_LOCAL/bin` such that `gp`
will find its ''shared'' library also there.
PARI (2.4.3) '''pre'''pends its build path (with `-L`) when using
`-lpari`, except for when it links `gp`[`-2.4`] "in place", but this
happens ''after'' the new shared library (`.so*`, `*.dll` on Cygwin) has
been copied and new symbolic links have been created. The new ''static''
library is built and copied later though, but that shouldn't matter unless
`gp` is statically linked on Cygwin, which shouldn't be the case.
If despite that something weird happens, this is IMHO limited to Cygwin;
you may attach your spkg install logs (`$SAGE_ROOT/spkg/logs/pari-*.log`)
such that we can check this.
We also didn't have problems with upgrading '''to''' 2.4.3 btw., except
that initially some dependencies of Sage's extension modules were missing
such that those didn't get rebuilt in the first place (and used the old
ones with a different version they had been linked to earlier).
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11130#comment:85>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
