#9896: upgrading from 4.5.3 to 4.6.alpha0 fails on OS X 10.6
------------------------------+---------------------------------------------
Reporter: jhpalmieri | Owner: GeorgSWeber
Type: defect | Status: needs_review
Priority: blocker | Milestone: sage-4.6
Component: build | Keywords: upgrade update dependencies PARI
NewPARI
Author: Leif Leonhardy | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
------------------------------+---------------------------------------------
Changes (by newvalueoldvalue):
* keywords: => upgrade update dependencies PARI NewPARI
* status: needs_info => needs_review
* author: => Leif Leonhardy
Comment:
I've attached a few patches / files and their diffs that make upgrading
from Sage < 4.6 (i.e. to the new PARI) work.
I think this is a general improvement (not limited to PARI upgrade),
though for e.g. the GMP/MPIR 2.1.2 upgrade (see #8664), more dependencies
(or some other mechanism) have to be added to {{{module_list.py}}} to
properly rebuild the Sage ''library'' (i.e. '''all''' ''extension
modules'' that depend on MPIR). Sage ''packages'' depending on an upgraded
spkg will now get rebuilt without the need to download unmodified "new"
versions (with just the patch level bumped in order to get them rebuilt).
I'm setting this to "needs review", though I've not yet uploaded a patch
to get around the specific ''Darwin'' linker problem (but I'll provide one
later).
When doing an "in-place" upgrade (i.e. keeping the old directory name),
the current patches should also fully work on MacOS X. A work-around to
the linker problem (i.e. when the Sage to be upgraded is located in a new
directory) is manually setting (and exporting) {{{LDSHARED}}} to the
output of {{{distutils.sysconfig.get_config_var("LDSHARED")}}} with the
second "word" ({{{-L...}}}) either dropped or replaced by {{{-L}}}
immediately followed by {{{$SAGE_ROOT/local/lib}}} (with {{{$SAGE_ROOT}}}
the actual directory name, not the environment variable; see also comments
above for more details).
Unfortunately we'll have to set up a Sage package server (or a special
directory on e.g. {{{www.sagemath.org}}}) to "fully" test this, i.e. by
''really'' running {{{sage -upgrade}}}.
On the other hand, the changes are quite small such that they should
easily be reviewed. The behavior can be tested by e.g. running {{{make}}}
with {{{SAGE_UPGRADING}}} set to "yes", faking some spkg was new (to see
that all dependent spkgs really get rebuilt) etc. .
One can also test it by doing a real upgrade from some '''vanilla'''
version to 4.6.alpha1, '''after that''' applying the patch to
{{{module_list.py}}} and copying over the new {{{spkg/install}}} and
{{{spkg/standard/deps}}}, then exporting {{{SAGE_UPGRADE=yes}}} and
running {{{make}}}. Then everything should be properly [re]built.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9896#comment:54>
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.
