Sage 4.6.alpha0 released
Mitesh Patel
We've released Sage 4.6.alpha0.
Source archive:
http://sage.math.washington.edu/home/release/sage-4.6.alpha0/sage-4.6.alpha0.tar
Upgrade path:
http://sage.math.washington.edu/home/release/sage-4.6.alpha0/sage-4.6.alpha0/
The long doctests pass for me on {bsd,redhawk,sage}.math.washington.edu.
The t2 build is in progress. Note: We've already had a lot of testing
of the PARI upgrade tickets with Jeroen Demeyer's 4.6.prealphas.
Thanks, Jeroen!
Please build, test, and report! We'd love to hear about your
experiences with this release.
== Tickets ==
Merged in sage-4.6.alpha0:
#9343: Robert Bradshaw, John Cremona, Jeroen Demeyer, William Stein,
David Kirkby: Upgrade PARI to svn snapshot 12577 - a pre-release of PARI
2.4.3. [Reviewed by Robert Bradshaw, John Cremona, Jeroen Demeyer,
William Stein, David Kirkby, Fran�ois Bissey, Leif Leonhardy]
#9591: Jeroen Demeyer, Mitesh Patel: Upgrade genus2reduction due to Pari
upgrade to svn snapshot 12577 - a pre-release of Pari 2.4.3 [Reviewed by
Fran�ois Bissey, Mitesh Patel, Leif Leonhardy]
#9592: John Cremona, Jeroen Demeyer, Rishikesh: Upgrade lcalc to work
with Pari svn snapshot 12577 - a pre-release of Pari 2.4.3 [Reviewed by
Jeroen Demeyer, Leif Leonhardy, Mitesh Patel]
#9636: Jeroen Demeyer: Catch output from PARI in Sage [Reviewed by Leif
Leonhardy]
#9750: Jeroen Demeyer: Document that PARI no longer assumes more than
GRH [Reviewed by John Cremona]
#9860: Leif Leonhardy, Jeroen Demeyer: Port changes in PARI 2.3.5.p4
(#9722) to current 2.4.3 [Reviewed by Jeroen Demeyer, Leif Leonhardy]
Rob Beezer
1) 64-bit Kubuntu 10.04 on Intel Core Duo
export SAGE64=yes
export MAKE="make -j4"
export SAGE_PARALLEL_SPKG_BUILD="YES"
make ptestlong
2) 32-bit Ubuntu 10.04 on 4-year-old Pentium-something
make testlong
John H Palmieri
> Hello,
>
> We've released Sage 4.6.alpha0.
>
> Source archive:
>
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.alpha0/sage-4.6...
> The long doctests pass for me on {bsd,redhawk,sage}.math.washington.edu.
> The t2 build is in progress. Note: We've already had a lot of testing
> of the PARI upgrade tickets with Jeroen Demeyer's 4.6.prealphas.
> Thanks, Jeroen!
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
seemed to work fine, but then Sage refused to start:
----------------------------------------------------------------------
| Sage Version 4.6.alpha0, Release Date: 2010-09-10 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
*** bug in PARI/GP (Segmentation Fault), please report
*** bug in PARI/GP (Segmentation Fault), please report
On one of the machines, building from scratch: all tests passed. (I
haven't tried on the other one yet.)
The skynet machines: on some I upgraded, on some I built from scratch.
Success so far on all but four machines. The two solaris machines
aren't done yet: one has upgraded successfully and has passed all
tests which have run so far, and the other is still in the build
process. Pari has built successfully on that machine.
The more serious problem is on the two itanium machines, cleo (ia64-
Linux-rhel) and iras (ia64-Linux-suse). On both of these, pari failed
to build, both from scratch and when upgrading:
>../src/modules/krasner.c: In function 'GetRamifiedPol':
../src/modules/krasner.c:878:1: error: unrecognizable insn:
(insn:TI 7910 7861 7937 509 (parallel [
(set (reg:DI 134 f6)
(asm_operands:DI ("xma.hu %0 = %2, %3, f0
;;
xma.l %1 = %2, %3, f0") ("=&f") 0 [
(reg:DI 135 f7)
(reg/v:DI 130 f2 [orig:1756 pmodg ] [1756])
]
[
(asm_input:DI ("f") (null):0)
(asm_input:DI ("f") (null):0)
]
[] ../src/modules/krasner.c:878))
(set (reg:DI 135 f7)
(asm_operands:DI ("xma.hu %0 = %2, %3, f0
;;
xma.l %1 = %2, %3, f0") ("=f") 1 [
(reg:DI 135 f7)
(reg/v:DI 130 f2 [orig:1756 pmodg ] [1756])
]
[
(asm_input:DI ("f") (null):0)
(asm_input:DI ("f") (null):0)
]
[] ../src/modules/krasner.c:878))
]) -1 (nil))
../src/modules/krasner.c:878:1: internal compiler error: in
get_attr_first_insn, at config/ia64/itanium2.md:1909
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Should I open a ticket for this?
--
John
Mitesh Patel
> On two different Intel Macs running OS X 10.6: an upgrade from 4.5.3
> seemed to work fine, but then Sage refused to start:
>
> ----------------------------------------------------------------------
> | Sage Version 4.6.alpha0, Release Date: 2010-09-10 |
> | Type notebook() for the GUI, and license() for information. |
> ----------------------------------------------------------------------
> **********************************************************************
> * *
> * Warning: this is a prerelease version, and it may be unstable. *
> * *
> **********************************************************************
> *** bug in PARI/GP (Segmentation Fault), please report
> *** bug in PARI/GP (Segmentation Fault), please report
>
>
> On one of the machines, building from scratch: all tests passed. (I
> haven't tried on the other one yet.)
Could you open a 4.6-blocker ticket for this? Upgrading from 4.5.3
worked for me on sage.math.
> The skynet machines: on some I upgraded, on some I built from scratch.
> Success so far on all but four machines. The two solaris machines
> aren't done yet: one has upgraded successfully and has passed all
> tests which have run so far, and the other is still in the build
> process. Pari has built successfully on that machine.
More data: My build from scratch on t2 was successful and the long
doctests passed.
Please do, as a 4.6-blocker. Maybe this is a problem with GCC 4.5.1 on
Itanium?
John H Palmieri
> On 09/11/2010 12:18 AM, John H Palmieri wrote:
>
>
>
>
>
> > On two different Intel Macs running OS X 10.6: an upgrade from 4.5.3
> > seemed to work fine, but then Sage refused to start:
>
> > ----------------------------------------------------------------------
> > | Sage Version 4.6.alpha0, Release Date: 2010-09-10 |
> > | Type notebook() for the GUI, and license() for information. |
> > ----------------------------------------------------------------------
> > **********************************************************************
> > * *
> > * Warning: this is a prerelease version, and it may be unstable. *
> > * *
> > **********************************************************************
> > *** bug in PARI/GP (Segmentation Fault), please report
> > *** bug in PARI/GP (Segmentation Fault), please report
>
> > On one of the machines, building from scratch: all tests passed. (I
> > haven't tried on the other one yet.)
>
> Could you open a 4.6-blocker ticket for this? Upgrading from 4.5.3
> worked for me on sage.math.
eno, flavius, lena, menas, taurus, and mark, although doctesting
hasn't quite finished on mark). I've only seen this problem on OS X.
See <http://trac.sagemath.org/sage_trac/ticket/9896>.
> > The skynet machines: on some I upgraded, on some I built from scratch.
> > Success so far on all but four machines. The two solaris machines
> > aren't done yet: one has upgraded successfully and has passed all
> > tests which have run so far, and the other is still in the build
> > process. Pari has built successfully on that machine.
>
> More data: My build from scratch on t2 was successful and the long
> doctests passed.
>
>
>
>
>
> > The more serious problem is on the two itanium machines, cleo (ia64-
> > Linux-rhel) and iras (ia64-Linux-suse). On both of these, pari failed
> > to build, both from scratch and when upgrading:
>
> Please do, as a 4.6-blocker. Maybe this is a problem with GCC 4.5.1 on
> Itanium?
--
John
John Cremona
but there are various spkgs which depend on pari which have to be
recompiled and relinked after installing the new pari spkg.
Personally I would not object to simply announcing that upgrading from
pre- to post-4.6 was not supported! But of course there maybe some
other underlying problem.
John
> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to sage-release...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.
>
>
Mitesh Patel
> I don't know enough about how the upgrade process is supposed to work,
> but there are various spkgs which depend on pari which have to be
> recompiled and relinked after installing the new pari spkg.
>
> Personally I would not object to simply announcing that upgrading from
> pre- to post-4.6 was not supported! But of course there maybe some
> other underlying problem.
Leif has noticed a potentially similar problem with upgrading the MPIR
package:
http://trac.sagemath.org/sage_trac/ticket/8664#comment:9
leif
> I don't know enough about how the upgrade process is supposed to work,
> but there are various spkgs which depend on pari which have to be
> recompiled and relinked after installing the new pari spkg.
See #8664 [1] for a similar discussion (regarding MPIR upgrade), with
some suggestions how one could make this work. (IMHO it *is* currently
broken, but we can in principle support it for 4.6 final.)
-Leif
_____________
[1] http://trac.sagemath.org/sage_trac/ticket/8664#comment:9 ff.
leif
> Leif has noticed a potentially similar problem with upgrading the MPIR
> package:
>
> http://trac.sagemath.org/sage_trac/ticket/8664#comment:9
:D Sorry, didn't notice your post...
-Leif
Dr. David Kirkby
> I don't know enough about how the upgrade process is supposed to work,
> but there are various spkgs which depend on pari which have to be
> recompiled and relinked after installing the new pari spkg.
>
> Personally I would not object to simply announcing that upgrading from
> pre- to post-4.6 was not supported! But of course there maybe some
> other underlying problem.
>
> John
IMHO,
rather than just annouce this, there should be a mechanism in Sage to prevent
it. I'm not sure of the best way, but a couple of options might be to
1) Prevent updates from versions more than X months old.
2) Increment the major version number when there are major changes, and stop
updates from something with a different major version.
John H Palmieri
deps (or I did something else wrong in the following): when I look at
deps, I see that the following spkgs depend on pari: eclib,
genus2reduction, lcalc, and sage. Upgrading to alpha0 upgrades all of
these except eclib, and I just forced an upgrade in which eclib would
also be reinstalled. I got the same error.
That is:
- I took a new 4.5.3 install.
- I deleted spkg/installed/eclib...
Then I ran ./sage -upgrade .... and it said
The following packages will be upgraded:
eclib-20100711 examples-4.6.alpha0 extcode-4.6.alpha0
genus2reduction-0.3.p8 lcalc-20100428-1.23.p2
pari-2.4.3.svn-12577.p5 sage-4.6.alpha0 sage_scripts-4.6.alpha0
It proceeded to install all of these, and the files which I think
eclib installs (libcurvesntl.dylib, libg0nntl.dylib, libjcntl.dylib,
librankntl.dylib) have the appropriate modification times.
So is there a hidden dependency on pari, or is the bug more subtle, or
am I just missing something?
--
John
John H Palmieri
> On Sep 11, 1:41 pm, leif <not.rea...@online.de> wrote:
>
> > Mitesh Patel wrote:
> > > Leif has noticed a potentially similar problem with upgrading the MPIR
> > > package:
>
> > >http://trac.sagemath.org/sage_trac/ticket/8664#comment:9
>
> > :D Sorry, didn't notice your post...
>
> > -Leif
>
> I don't know if this is the issue. If it is, there might be a bug in
> deps (or I did something else wrong in the following): when I look at
> deps, I see that the following spkgs depend on pari: eclib,
> genus2reduction, lcalc, and sage.
the same experiment forcing a reinstallation of gap as well, but with
the same error. I also tried "./sage -ba" at the end, but no luck.
--
John
leif
> On Sep 11, 1:41 pm, leif <not.rea...@online.de> wrote:
>> Mitesh Patel wrote:
>>> Leif has noticed a potentially similar problem with upgrading the MPIR
>>> package:
>>
>>> http://trac.sagemath.org/sage_trac/ticket/8664#comment:9
>
> deps (or I did something else wrong in the following): when I look at
> deps, I see that the following spkgs depend on pari: eclib,
> genus2reduction, lcalc, and sage. Upgrading to alpha0 upgrades all of
> these except eclib, and I just forced an upgrade in which eclib would
> also be reinstalled. I got the same error.
>
> That is:
>
> - I took a new 4.5.3 install.
> - I deleted spkg/installed/eclib...
>
> Then I ran ./sage -upgrade .... and it said
>
> The following packages will be upgraded:
>
> eclib-20100711 examples-4.6.alpha0 extcode-4.6.alpha0
> genus2reduction-0.3.p8 lcalc-20100428-1.23.p2
> pari-2.4.3.svn-12577.p5 sage-4.6.alpha0 sage_scripts-4.6.alpha0
>
> It proceeded to install all of these, and the files which I think
> eclib installs (libcurvesntl.dylib, libg0nntl.dylib, libjcntl.dylib,
> librankntl.dylib) have the appropriate modification times.
>
> So is there a hidden dependency on pari, or is the bug more subtle, or
> am I just missing something?
Any suspicious things in PARI's install log?
Are the time stamps of libpari* also ok?
Can you try (if you did not already) reinstalling PARI with SAGE_CHECK=yes?
-Leif
Justin C. Walker
On Sep 10, 2010, at 05:13 , Mitesh Patel wrote:
> Hello,
>
> We've released Sage 4.6.alpha0.
>
> Source archive:
>
> http://sage.math.washington.edu/home/release/sage-4.6.alpha0/sage-4.6.alpha0.tar
>
> Upgrade path:
>
> http://sage.math.washington.edu/home/release/sage-4.6.alpha0/sage-4.6.alpha0/
Built as an upgrade to 4.5.3, on Mac OS X 10.5.8 (Dual Quad Xeon), w.
no problems. Testing (ptestlong) yielded two failures:
------------------------------------------------
The following tests failed:
sage -t -long devel/sage/sage/libs/mwrank/interface.py # 4 doctests
failed
sage -t -long devel/sage/sage/schemes/elliptic_curves/
ell_rational_field.py # 1 doctests failed
------------------------------------------------
The log is @ sage.math.washington.edu:~justin/logs/ptest-4.6.log.
Tried the full test twice, and the two above several times
individually. The failures were repeatable.
Built from scratch on Mac OS X 10.6.4 (Core i7), w. no problems. All
tests passed (ptestlong).
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
My wife 'n kids 'n dogs are gone,
I can't get Jesus on the phone,
But Ol' Milwaukee's Best is my best friend.
-----------
John Cremona
>
> On Sep 10, 2010, at 05:13 , Mitesh Patel wrote:
>
>> Hello,
>>
>> We've released Sage 4.6.alpha0.
>>
>> Source archive:
>>
>>
>> http://sage.math.washington.edu/home/release/sage-4.6.alpha0/sage-4.6.alpha0.tar
>>
>> Upgrade path:
>>
>>
>> http://sage.math.washington.edu/home/release/sage-4.6.alpha0/sage-4.6.alpha0/
>
> Built as an upgrade to 4.5.3, on Mac OS X 10.5.8 (Dual Quad Xeon), w. no
> problems. Testing (ptestlong) yielded two failures:
> ------------------------------------------------
> The following tests failed:
>
> sage -t -long devel/sage/sage/libs/mwrank/interface.py # 4 doctests
> failed
> sage -t -long
> devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py # 1 doctests
> failed
Both these are happening during or after calls to eclib code, and
eclib uses the pari library. Did your upgrade rebuild eclib? Could
you try rebuilding it withe sage -f and try those tests again?
John
> ------------------------------------------------
> The log is @ sage.math.washington.edu:~justin/logs/ptest-4.6.log. Tried the
> full test twice, and the two above several times individually. The failures
> were repeatable.
>
> Built from scratch on Mac OS X 10.6.4 (Core i7), w. no problems. All tests
> passed (ptestlong).
>
> Justin
>
>
> --
> Justin C. Walker, Curmudgeon at Large
> Institute for the Absorption of Federal Funds
> -----------
> My wife 'n kids 'n dogs are gone,
> I can't get Jesus on the phone,
> But Ol' Milwaukee's Best is my best friend.
> -----------
>
>
Justin C. Walker
On Sep 12, 2010, at 10:44 , John Cremona wrote:
> On Sun, Sep 12, 2010 at 6:16 PM, Justin C. Walker <jus...@mac.com>
> wrote:
>>
>> On Sep 10, 2010, at 05:13 , Mitesh Patel wrote:
[snip]
>> Built as an upgrade to 4.5.3, on Mac OS X 10.5.8 (Dual Quad Xeon),
>> w. no
>> problems. Testing (ptestlong) yielded two failures:
>> ------------------------------------------------
>> The following tests failed:
>>
>> sage -t -long devel/sage/sage/libs/mwrank/interface.py # 4
>> doctests
>> failed
>> sage -t -long
>> devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py # 1
>> doctests
>> failed
>
> Both these are happening during or after calls to eclib code, and
> eclib uses the pari library. Did your upgrade rebuild eclib? Could
> you try rebuilding it withe sage -f and try those tests again?
I'm happy to try this. I should be using eclib-20100711.spkg, right?
FWIW, spkg/logs/eclib-20100711.log has a time-stamp of Sept 11, 2010,
around the time that the tests were running.
Also, this is the last line in the log file:
sage: eclib-20100711 is already installed
Not sure what to make of that. I had built this version on a 4.5.3
base, if that sheds light. And run the full 'ptestlong' suite twice.
Justin
--
Justin C. Walker
Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
--
Build a man a fire and he'll be warm
for a night.
Set a man on fire and he'll be warm
for the rest of his life.
John Cremona
rebuilt since it uses the pari library and that has changed. There
has been some discussion on another thread (I think) about checking
these dependencies, since the upgrade script really should have known
about this dependency.
John
Justin C. Walker
On Sep 12, 2010, at 11:12 , John Cremona wrote:
> The point is that even though eclib has not changed, it should be
> rebuilt since it uses the pari library and that has changed. There
> has been some discussion on another thread (I think) about checking
> these dependencies, since the upgrade script really should have known
> about this dependency.
I'm puzzled. I did the "-f" thing, and checked the 9/11 and 9/12
logs. They look much the same. Doesn't that mean that eclib was
rebuilt when I did the initial install/upgrade to 4.6.a0?
In any case, after forcing the install of eclib, I reran the full test
suite, and all tests passed (Mac OS X, 10.5.8, Dual Quad Xeon).
Thanks for the gentle nudge...
Justin
--
Justin C. Walker, Curmudgeon-At-Large, Director
Institute for the Enhancement of the Director's Income
--------
The path of least resistance:
it's not just for electricity any more.
--------
John Cremona
>
> On Sep 12, 2010, at 11:12 , John Cremona wrote:
>
>> The point is that even though eclib has not changed, it should be
>> rebuilt since it uses the pari library and that has changed. There
>> has been some discussion on another thread (I think) about checking
>> these dependencies, since the upgrade script really should have known
>> about this dependency.
>
> I'm puzzled. I did the "-f" thing, and checked the 9/11 and 9/12 logs.
> They look much the same. Doesn't that mean that eclib was rebuilt when I
> did the initial install/upgrade to 4.6.a0?
I don't know! The building and linking of eclib will surely look the
same even if different versions of libpari are linked into the
executables. And since things are dynamically linked, it will hurt if
the versions available at run-time do not match those which the
programs were compiled for.
But I do not really know what I am talking about (as is probably apparent!).
>
> In any case, after forcing the install of eclib, I reran the full test
> suite, and all tests passed (Mac OS X, 10.5.8, Dual Quad Xeon).
>
Good!
John
> Thanks for the gentle nudge...
>
> Justin
>
> --
> Justin C. Walker, Curmudgeon-At-Large, Director
> Institute for the Enhancement of the Director's Income
> --------
> The path of least resistance:
> it's not just for electricity any more.
> --------
>
>
>
leif
> On Sun, Sep 12, 2010 at 9:55 PM, Justin C. Walker <jus...@mac.com> wrote:
>>
>> On Sep 12, 2010, at 11:12 , John Cremona wrote:
>>
>>> The point is that even though eclib has not changed, it should be
>>> rebuilt since it uses the pari library and that has changed. There
>>> has been some discussion on another thread (I think) about checking
>>> these dependencies, since the upgrade script really should have known
>>> about this dependency.
>>
>> I'm puzzled. I did the "-f" thing, and checked the 9/11 and 9/12 logs.
>> They look much the same. Doesn't that mean that eclib was rebuilt when I
>> did the initial install/upgrade to 4.6.a0?
Well, 'make' "knows" about that dependency, and tries to rebuild eclib,
but since 'sage-spkg' is called without '-f' in 'spkg/standard/deps'
(the Makefile), it thinks it is smarter and simply pretends rebuilding
eclib by touching 'spkg/installed/eclib-20100711'.
'spkg/logs/eclib-20100711' should then contain a note on that ("... is
already installed").
> I don't know! The building and linking of eclib will surely look the
> same even if different versions of libpari are linked into the
> executables. And since things are dynamically linked, it will hurt if
> the versions available at run-time do not match those which the
> programs were compiled for.
eclib (if not getting rebuilt) should then use the old shared library of
PARI, since the filenames differ ('libpari-gmp.*' vs.
'libpari-gmp-2.4.*' [and also the so-versions], but the dynamic loader
might mess this up since most symbols have the same name in both libs
and it might resolve eclib's from an already loaded new version of the
PARI library).
> But I do not really know what I am talking about (as is probably apparent!).
>
>>
>> In any case, after forcing the install of eclib, I reran the full test
>> suite, and all tests passed (Mac OS X, 10.5.8, Dual Quad Xeon).
>>
>
> Good!
Yes. ;-)
P.S.: I just noticed (at least some of) eclib's test programs link
against a *systemwide* PARI lib if present.
-Leif
John Cremona
John
Justin C. Walker
On Sep 13, 2010, at 05:18 , leif wrote:
> John Cremona wrote:
>> On Sun, Sep 12, 2010 at 9:55 PM, Justin C. Walker <jus...@mac.com> wrote:
>>>
>>> On Sep 12, 2010, at 11:12 , John Cremona wrote:
>>>
>>>> The point is that even though eclib has not changed, it should be
>>>> rebuilt since it uses the pari library and that has changed. There
>>>> has been some discussion on another thread (I think) about checking
>>>> these dependencies, since the upgrade script really should have known
>>>> about this dependency.
>>>
>>> I'm puzzled. I did the "-f" thing, and checked the 9/11 and 9/12 logs.
>>> They look much the same. Doesn't that mean that eclib was rebuilt when I
>>> did the initial install/upgrade to 4.6.a0?
>
> Well, 'make' "knows" about that dependency, and tries to rebuild eclib,
> but since 'sage-spkg' is called without '-f' in 'spkg/standard/deps'
> (the Makefile), it thinks it is smarter and simply pretends rebuilding
> eclib by touching 'spkg/installed/eclib-20100711'.
>
> 'spkg/logs/eclib-20100711' should then contain a note on that ("... is
> already installed").
Thanks for noting this. I did mention, earlier in this thread, that this was noted in the eclib log, but it got lost in the noise. It preceded the last attempt to build (with "sage -f"), so that explains my confusion. The log shows two instances of "Extracting...", the first from the initial build (4.5.3.alpha1), and the second from the "sage -f".
To bad the logs aren't time-stamped at the start of a run :-}
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
I'm beginning to like the cut of his jibberish.
-----------
Justin C. Walker
On Sep 13, 2010, at 01:50 , John Cremona wrote:
> On Sun, Sep 12, 2010 at 9:55 PM, Justin C. Walker <jus...@mac.com> wrote:
>>
>> On Sep 12, 2010, at 11:12 , John Cremona wrote:
>>
>>> The point is that even though eclib has not changed, it should be
>>> rebuilt since it uses the pari library and that has changed. There
>>> has been some discussion on another thread (I think) about checking
>>> these dependencies, since the upgrade script really should have known
>>> about this dependency.
>>
>> I'm puzzled. I did the "-f" thing, and checked the 9/11 and 9/12 logs.
>> They look much the same. Doesn't that mean that eclib was rebuilt when I
>> did the initial install/upgrade to 4.6.a0?
>
> I don't know! The building and linking of eclib will surely look the
> same even if different versions of libpari are linked into the
> executables. And since things are dynamically linked, it will hurt if
> the versions available at run-time do not match those which the
> programs were compiled for.
Thanks for clarifying, and to Leif for even more clarification!
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Absorption of Federal Funds
--------
If you're not confused,
You're not paying attention
--------
leif
> [...]
> To bad the logs aren't time-stamped at the start of a run :-}
I don't like this either.
[Instead, the output of 'uname -a' and 'gcc -v' -- regardless what the
package uses/requires -- is logged. The *verbose* tar extraction also
blows up many logs...]
Can you open a ticket for that?
(Also, a time stamp when the build/installation finished wouldn't be
bad. I think there are already tickets for improving 'sage-spkg' though.)
-Leif
Dr. David Kirkby
Also dumb is the fact that $CC -v is used irrespective of what the compiler is.
There's a script local/bin/testcc.sh which reports the compiler. The option to
show the version should depend on what the compiler is. For Sun's it should be
-V. For other compilers, it should no doubt be something else.
Dave
Justin C. Walker
Done [both beginning and end] (#9905). Thanks for the nudge :-}
FWIW, I noticed that the entries in spkg/installed might work for an "end" stamp, but I think it would be better for the timestamps to be in the log files. Otherwise, when one upgrades, the previous information is lost.
Justin
--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's income
-----------
--
They said it couldn't be done, but sometimes,
it doesn't work out that way.
- Casey Stengel
--