sage-4.7.alpha5 released
Jeroen Demeyer
We're releasing Sage 4.7.alpha5.
Source archive:
http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5.tar
Upgrade path:
http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5/
Please build, test, and report! We'd love to hear about your
experiences with this release.
== Notes ==
* The 4.7 release cycle is now considered feature-complete. Essentially
only blocker tickets or trivial patches will be considered for inclusion
in the next development releases.
* Ticket #11027 (Schur matrix decomposition over RDF/CDF) was unmerged
because of doctest failures on various machines.
* Because of issues with SAGE_SPKG_INSTALL_DOCS and Sphinx,
the tickets #10826 (numpy), #10827 (cython), #10828 (matplotlib) were
unmerged.
== Known issues ==
* Some doctests fail on bsd.math (OS X 10.6 i386), when compiling in
64-bit mode due to SAGE64 verbosity. This is #10303.
* Various packages on various systems do not compile with gcc 4.6.0.
This will be sorted out during the sage-4.7.1 release cycle.
== Tickets ==
* We closed 188 tickets in this release. For details, see
http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/tickets.html
Closed tickets:
#8613: __dir__() / tab completion returns nonexistent attributes
[Reviewed by Simon King]
#10994: Bug in permutation_automorphism_group for linear codes [Reviewed
by Robert Miller]
#11032: automorphism_group_binary_code crashes Sage when it can't
allocate enough memory [Reviewed by Robert Miller]
Merged in sage-4.7.alpha5:
#7105: John Palmieri: change search_doc and search_src so the links are
opened in a new tab/window [Reviewed by Karl-Dieter Crisman]
#8614: William Stein: Optimize creation of modular symbols spaces by
speeding up quotienting out by 2-term relations [Reviewed by Alex
Ghitsa, David Loeffler, John Cremona]
#8998: William Stein: galois_action on cusps has a bug [Reviewed by John
Cremona]
#9028: Andrew Hou, Benjamin Jones: Basic Stats - Standard Deviation
[Reviewed by Simon Spicer]
#9094: Robert Bradshaw, Maarten Derickx: is_square and sqrt for
polynomials and fraction fields [Reviewed by John Cremona, Marco Streng,
Robert Bradshaw]
#9109: Florent Hivert: Fast cython class for maps between finite sets.
[Reviewed by Mike Hansen, Nicolas M. Thiéry]
#9371: Jamie Weigandt, Aly.deines: Implement E.two_torsion_rank() over
number fields [Reviewed by John Cremona, Gagan Sekhon]
#9497: Martin Albrecht, John Palmieri: Fix the Singular spkg so it can
take advantage of building in parallel [Reviewed by David Kirkby]
#9705: William Stein: trouble with long lines in notebook magma mode
[Reviewed by Martin Raum]
#9969: Fredrik Johansson: Update extension code for mpmath-0.17
[Reviewed by François Bissey]
#10055: Thierry Monteil: Fix typos and formatting in
sage/combinat/words/notes/historic.txt and rename it history.txt
[Reviewed by Sébastien Labbé, Jeroen Demeyer]
#10109: Jeroen Demeyer: Document sig_on() in the developer manual
[Reviewed by Volker Braun]
#10124: Douglas McNeil: Graph drawing has issues with edge labels
[Reviewed by Nathann Cohen]
#10601: Simon Spicer: QuaternionAlgebra constructor does not work for
python int [Reviewed by Rob Beezer]
#10761: Simon Spicer: Numerical approximation of an algebraic number
raises a ValueError [Reviewed by Rob Beezer]
#10794: Rob Beezer: QR decomposition for matrices over exact rings
[Reviewed by Simon Spicer]
#10796: Robert Bradshaw, Karl-Dieter Crisman: Platonic solid
constructors scale and translate in the wrong order. [Reviewed by
Karl-Dieter Crisman, Robert Bradshaw]
#10799: Miguel Marco: Solved the problem to compute resultants on
certain variable orders [Reviewed by Simon Spicer]
#10832: John Cremona: bug in simon_two_descent() [Reviewed by Chris
Wuthrich]
#10840: John Cremona: bug in saturation for elliptic curves over Q
[Reviewed by Gagan Sekhon]
#10847: Jason Grout: matrix_plot can now plot subdivisions [Reviewed by
Karl-Dieter Crisman, John Palmieri]
#10858: Johan Bosman: segfault when multiplying 0x0 dense matrix with a
vector. [Reviewed by Maarten Derickx]
#10865: Minh Van Nguyen, Mariah Lenox: update copyright years to include
2011 [Reviewed by Minh Van Nguyen, Mariah Lenox]
#10905: Nathann Cohen: shortest path all pairs through BFS computations.
[Reviewed by Yann Laigle-Chapuy]
#10933: Maarten Derickx: time of magma command fails inside function
[Reviewed by Martin Raum]
#10934: John Palmieri: is_maximal is broken [Reviewed by Simon Spicer]
#10939: Nicolas M. Thiéry: Relabel a graph according to a bijective
function [Reviewed by Nathann Cohen]
#10986: François Bissey: building ecl fails in case the installed etags
is actually exuberant-ctags [Reviewed by Harald Schilly, Simon King]
#10987: Martin Raum: Add optional arguement to decomposition_of_subspace
making restrict not check the subspace [Reviewed by Rob Beezer]
#11007: William Stein: heegner points -- a nonsquarefree case [Reviewed
by Jennifer Balakrishnan]
#11019: Martin Albrecht: BooleanPolynomial.lex_lead() shouldn't crash on
zero [Reviewed by Alexander Dreyer]
#11033: Robert Miller: fixes and improvements to automorphism groups of
linear codes [Reviewed by David Joyner]
#11046: Nathann Cohen: Some comments in the code of SparseGraph
[Reviewed by Robert Miller]
#11128: Sébastien Labbé: Limit case bug for conjugate_position in words
[Reviewed by Alexandre Blondin Massé]
#11136: David Kirkby: Upgrade sqlite to the newest upstream release
(3.7.5) [Reviewed by Mariah Lenox, François Bissey]
#11141: John Palmieri: update SAGE_ROOT/local/bin/.hgignore [Reviewed by
David Kirkby]
#11156: Nicolas M. Thiéry: sage.misc.sage_unittest.InstanceTester should
call its base's __init__ [Reviewed by François Bissey]
#11163: William Stein: documentation of p-adic L-function
order_of_vanishing is very wrong [Reviewed by David Loeffler]
Justin C. Walker
On Apr 20, 2011, at 00:10 , Jeroen Demeyer wrote:
> Dear Sage lovers,
>
> We're releasing Sage 4.7.alpha5.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5.tar
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5/
I tried an upgrade from alpha4, and ran into this:
pulling from /Users/Sage/sage-4.7.alpha4/spkg/build/extcode-4.7.alpha5
searching for changes
no changes found
merging .hgtags
tool hgmerge can't handle binary
Is this expected? Unusual? Bug?
Why in particular, are we "merging"? Isn't the tarball reflective of a fully merged/committed tree?
FWIW, during the upgrade process, I often see a stuck 'FileMerge' process and a bunch of complaints about .hgtags, but it has yet to bork the build.
Thanks!
Justin
--
Justin C. Walker, Curmudgeon at Large
Director
Institute for the Enhancement of the Director's Income
-----------
Nobody knows the trouble I've been
-----------
Justin C. Walker
On Apr 20, 2011, at 14:04 , Justin C. Walker wrote:
>
> On Apr 20, 2011, at 00:10 , Jeroen Demeyer wrote:
>
>> Dear Sage lovers,
>>
>> We're releasing Sage 4.7.alpha5.
>>
>> Source archive:
>>
>> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5.tar
>>
>> Upgrade path:
>>
>> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5/
>
> I tried an upgrade from alpha4, and ran into this:
>
> pulling from /Users/Sage/sage-4.7.alpha4/spkg/build/extcode-4.7.alpha5
> searching for changes
> no changes found
> merging .hgtags
> tool hgmerge can't handle binary
Sorry - incomplete report: the upgrade hung at this point, and the only way out was "^C".
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
If it weren't for carbon-14, I wouldn't date at all.
-----------
Samuel Lelievre
> Dear Sage lovers,
>
> We're releasing Sage 4.7.alpha5.
Dear Jeroen,
thank you for this new alpha!
On a 2007 MacBook Pro under Mac OS X 10.5.8, the build failed
with a segmentation fault while building polybori. Excerpt below.
Samuel
$ date -u "+Date: %F %T Z"
Date: 2011-04-20 20:52:31 Z
$ uname -a
Darwin U 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT
2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)
$ cd /Applications/sage-4.7.alpha5
$ export MAKE="make -j2"
$ export SAGE_PARALLEL_SPKG_BUILD="yes"
$ make build
<snip>
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -g -O2 -MT
newton.lo -MD -MP -MF .deps/newton.Tpo -c newton.c -fno-common -DPIC
-o .libs/newton.o
In file included from polybori/include/order_tags.h:16,
from polybori/include/pbori_tags.h:17,
from polybori/include/COrderingTags.h:21,
from polybori/include/CStackSelector.h:28,
from polybori/include/COrderedIter.h:27,
from polybori/include/COrderingBase.h:22,
from polybori/include/COrderingFacade.h:23,
from polybori/include/DegLexOrder.h:20,
from polybori/include/pbori_order.h:26,
from polybori/include/polybori.h:33,
from groebner/src/groebner_defs.h:10,
from groebner/src/pairs.h:10,
from groebner/src/pairs.cc:10:
polybori/include/pbori_defs.h:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -g -O2 -MT
gnewton.lo -MD -MP -MF .deps/gnewton.Tpo -c gnewton.c -fno-common
-DPIC -o .libs/gnewton.o
scons: *** [groebner/src/pairs.os] Error 1
scons: building terminated because of errors.
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -g -O2 -MT
newton.lo -MD -MP -MF .deps/newton.Tpo -c newton.c -o newton.o
>/dev/null 2>&1
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -g -O2 -MT
gnewton.lo -MD -MP -MF .deps/gnewton.Tpo -c gnewton.c -o gnewton.o
>/dev/null 2>&1
Error building PolyBoRi.
real 7m43.581s
user 4m8.374s
sys 0m30.468s
sage: An error occurred while installing polybori-0.7.0.p2
Please email sage-devel http://groups.google.com/group/sage-devel
explaining the problem and send the relevant part of
of /Applications/sage-4.7.alpha5/install.log. Describe your computer,
operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/Applications/sage-4.7.alpha5/spkg/build/polybori-0.7.0.p2 and type
'make check' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd '/Applications/sage-4.7.alpha5/spkg/build/polybori-0.7.0.p2' &&
'/Applications/sage-4.7.alpha5/sage' -sh)
When you are done debugging, you can type "exit" to leave the
subshell.
make[1]: *** [installed/polybori-0.7.0.p2] Error 1
make[1]: *** Waiting for unfinished jobs....
<snip>
leif
> Dear Sage lovers,
>
> We're releasing Sage 4.7.alpha5.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5.tar
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5/
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
Ubuntu 9.04 x86_64 (Core2, gcc 4.3.3)
make build: OK (sequential build)
make doc: OK (no errors, no warnings)
make testlong: OK (all tests passed)
-Leif
Alex Ghitza
On Wed, 20 Apr 2011 09:10:48 +0200, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> We're releasing Sage 4.7.alpha5.
>
> experiences with this release.
Parallel build and long tests successful on
Linux 2.6.18-238.9.1.el5 #1 SMP Fri Mar 18 12:42:39 EDT 2011 x86_64 GNU/Linux
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
Best,
Alex
--
Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia
Jeroen Demeyer
>> I tried an upgrade from alpha4, and ran into this:
more flexibility, all alphas are essentially independent, i.e. alpha5 is
*not* based on alpha4). Upgrading from a stable version to an alpha
should still work.
Jeroen.
Jeroen Demeyer
> On a 2007 MacBook Pro under Mac OS X 10.5.8, the build failed
> with a segmentation fault while building polybori. Excerpt below.
Is this using the most recent XCode for that machine?
Harald Schilly
Justin C. Walker
On Apr 21, 2011, at 01:31 , Jeroen Demeyer wrote:
> On 2011-04-20 23:07, Justin C. Walker wrote:
>>> I tried an upgrade from alpha4, and ran into this:
> In general, upgrading *from* alphas is not supported anymore (to allow
> more flexibility, all alphas are essentially independent, i.e. alpha5 is
> *not* based on alpha4).
That's a bit too weird for words. If it's not based on a4, then what? Why have a string of alphas, then? What's the point?
When'd this happen? Did I miss a discussion?
> Upgrading from a stable version to an alpha should still work.
Right.
Why don't we just do away with upgrading? It seems like a lot of work for little reward. Why would I sacrifice a working release to a questionable alpha?
Justin
--
Justin C. Walker, Curmudgeon at Large
Institute for the Absorption of Federal Funds
-----------
I'm beginning to like the cut of his jibberish.
-----------
John Cremona
based on the previous full release. It's the way the current release
manager (who is doing a fantastically good job, thanks Jeroen!) find
most convenient.
I agree that it makes upgrade less useful; I gave up on upgrade a
long time ago, and build every alpha, rc, and all from scratch. I
suggest that you do the same!
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.
>
>
leif
> line 204, in frompickle
> env = pickle.load(picklefile)
> AttributeError: 'module' object has no attribute '_TranslationProxy'
> make: *** [doc-html] Error 1
So apparently some wrong Python path... (Sage's Sphinx is now at 1.0.4)
(<) 2ct,
-Leif
> I also ran ./sage -t devel/sage-main and a couple of tests timed out.
> I'll repeat it with "-long" and report all failing tests.
>
> H
>
Harald Schilly
> So apparently some wrong Python path...
Ahh, i could have seen that. Well, i guess it will work when i delete it.
H
Samuel Lelievre
Yes, it's XCode 3.1.4, the latest XCode for Mac OS X 10.5.x.
XCode 3.2.x or 4.x require Mac OS X 10.6.x.
leif
> It has been true for most of the last year that every alpha has been
> based on the previous full release. It's the way the current release
> manager (who is doing a fantastically good job, thanks Jeroen!) find
> most convenient.
Agree. Less convenient for "developers" though (especially since there's
no clean line between Sage users and developers, which is good in general).
> I agree that it makes upgrade less useful; I gave up on upgrade a
> long time ago, and build every alpha, rc, and all from scratch. I
> suggest that you do the same!
I /started/ doing upgrades in the mid of last year... ;-)
For "end users", upgrading (at least from "finals" [to "finals"]) might
still be worthwhile, depending on the amount and type of changes between
releases. Build time may in the worst case get the same, but download
size will certainly remain smaller.
And regularly typing "sage -upgrade" is some kind of user-friendly ;-)
(despite the scary warning message, at least if one backs up the sane
installation).
-Leif
> John
>
> On Thu, Apr 21, 2011 at 10:23 AM, Justin C. Walker <jus...@mac.com> wrote:
>> On Apr 21, 2011, at 01:31 , Jeroen Demeyer wrote:
>>
>>> On 2011-04-20 23:07, Justin C. Walker wrote:
>>>>> I tried an upgrade from alpha4, and ran into this:
>>> In general, upgrading *from* alphas is not supported anymore (to allow
>>> more flexibility, all alphas are essentially independent, i.e. alpha5 is
>>> *not* based on alpha4).
>> That's a bit too weird for words. If it's not based on a4, then what? Why have a string of alphas, then? What's the point?
Convenience for the release manager. ;-)
>>
>> When'd this happen? Did I miss a discussion?
I remember there's been some discussion last year. But I've been away
for a while as you might know.
>>> Upgrading from a stable version to an alpha should still work.
>> Right.
>>
>> Why don't we just do away with upgrading? It seems like a lot of work for little reward. Why would I sacrifice a working release to a questionable alpha?
See above. It's always safe to first make a copy (or backup) of the
working installation before performing an upgrade on it.
leif
Nevertheless, should get fixed from Sage's side, or others will run into
the same.
-Leif
Harald Schilly
On Thursday, April 21, 2011 11:13:58 AM UTC+2, Harald Schilly wrote:
I also ran ./sage -t devel/sage-main and a couple of tests timed out. I'll repeat it with "-long" and report all failing tests.
Florent Hivert
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5.tar
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5/
>
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
Parallel build and ptestlong successful on
openSUSE 11.3 (x86_64)
Linux 2.6.34.7-0.7-desktop #1 SMP PREEMPT 2010-12-13 11:13:53 +0100 x86_64 GNU/Linux
gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]
Good work !
Cheers,
Florent
John Cremona
32- and 64-bit, SuSE 32-bit) I have stopped reporting successful
builds and tests, and only report failures when they don't seem to
have been reported already.
I assume that is as helpful to release managers as if I sent in
positive reports?
John
Jeroen Demeyer
> Now there are buildbots and my systems are all pretty standard (ubuntu
> 32- and 64-bit, SuSE 32-bit) I have stopped reporting successful
> builds and tests, and only report failures when they don't seem to
> have been reported already.
>
> I assume that is as helpful to release managers as if I sent in
> positive reports?
Jeroen.
Jeroen Demeyer
> Yes, it's XCode 3.1.4, the latest XCode for Mac OS X 10.5.x.
> XCode 3.2.x or 4.x require Mac OS X 10.6.x.
I'm afraid you're out of luck then. The error message clearly indicates
a bug within gcc itself. Essentially the only solution is compiling a
newer version of gcc (but not version 4.6.0) from scratch. I have no
idea how easy/difficult this is on a Mac.
Jeroen.
kcrisman
OS X 10.4 box, and 4.2.1 on the 10.6 one (see a different thread for
why Mac has stuck with this). We haven't had any problems with others
on 10.5 recently, I don't think, but this is a recent upgrade in
PBR.
Also, I assume this is with an Intel chip? (I don't remember exactly
when the switch was - 2007 sounds around that time.)
Georg W. or Marshall, have you built any recent alphas on a machine
like that?
The new PolyBoRi was added in #10797, alpha2, for reference.
- kcrisman
Samuel Lelievre
2011-04-21 Jeroen Demeyer:
> On 2011-04-21 14:50, Samuel Lelievre wrote:
>> Yes, it's XCode 3.1.4, the latest XCode for Mac OS X 10.5.x.
>> XCode 3.2.x or 4.x require Mac OS X 10.6.x.
>
> I'm afraid you're out of luck then. The error message clearly indicates
> a bug within gcc itself. Essentially the only solution is compiling a
> newer version of gcc (but not version 4.6.0) from scratch. I have no
> idea how easy/difficult this is on a Mac.
2011-04-21 kcrisman:
kcrisman: yes it's intel (cf 'uname -a'), and here is what 'gcc -v' gives.
$ uname -a
Darwin U 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT
2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)
The strange thing is I had no problem with earlier 4.7alphas.
Would it make sense to just try 'make build' again?
Jeroen: I already have several versions of gcc installed.
$ ls /usr/bin/gcc*
/usr/bin/gcc /usr/bin/gcc-3.3 /usr/bin/gcc-4.0 /usr/bin/gcc-4.2
Presently, /usr/bin/gcc is an alias to /usr/bin/gcc-4.0 but I could
change that and make it an alias to gcc-4.2.
$ /usr/bin/gcc-4.0 -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)
$ /usr/bin/gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure
--disable-checking --enable-werror --prefix=/usr
--mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin9
--with-gxx-include-dir=/usr/include/c++/4.0.0
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
Other than that, it's easy to get newer versions of gcc via Fink or MacPorts.
I do have both Fink and MacPorts, and gcc 4.4 in both, maybe others too.
But I remember that under Mac OS X, before compiling Sage, one should
remove anything that has to do with Fink and MacPorts from the PATH.
But I could make /usr/bin/gcc an alias to /sw/bin/gcc in order to use gcc 4.4
without having Fink (/sw) or MacPorts (/opt) stuff in my PATH.
Samuel
kcrisman
one box, currently running long tests and doing fine.
> The strange thing is I had no problem with earlier 4.7alphas.
should have caused any trouble, but there is no patch posted so I
suppose it's possible.
> Would it make sense to just try 'make build' again?
>
where it left off. Sometimes there is just a random failure.
But please report if it's not!
- kcrisman
Dima Pasechnik
come with Xcode, or at least
ones that are not "Apple build".
Samuel, don't you have gcc-4.2.1 installed as a part of Xcode?
You can switch to it then.
>
> Jeroen.
gsw
it would be very unfortunate if our "you can use the latest XCode for
your OS X version" assumption would not hold anymore. I did build
Sage-4.7.alpha4 with no problems (and only the known doctest issues)
on MacIntel with Mac OS X 10.4.11 with the "latest Tiger" XCode 2.5
(gcc 4.0.1 "Apple build 5370"). Apart from switching to other XCode
versions (older ones than XCode 3.1.4 with gcc 4.0.1 "Apple build
5493"), or using the like of MacPorts/Fink/Gentoo Prefix, (or
switching to OS X 10.6 "Snow Leopard", which is inexpensive,) I guess
the solution proposed by Dima is the only one remaining for OS X 10.5
"Leopard".
@Samuel:
First of all, thank you for reporting this!
Could you please post what the following gives on your system, if you
type at the command line:
gcc<TAB><TAB>
(for me, that gives: "gcc gcc-3.3 gcc-4.0
gcc_select"), and what gives:
gcc_select --help
(for me, the latter gives:
"
usage: gcc_select [-n] [-force] [2 | 3 | 3.<number> | 4.<number> ] [-h
| --help] [-v | --version]
[-l | --list] [-root]
2 Select gcc 2.95.2 as the default compiler.
3 Select gcc 3.1 as the default compiler.
3.x Select gcc 3.x as the default compiler.
4.x Select gcc 4.x as the default compiler.
-force Ensure the links are correct for the specified version
even if it maches the current default version.
-h Display this help info.
--help Same as -h.
-l List available compiler versions.
--list Same as -l.
-n Show commands to do selection but do not execute them.
-root Skip 'root' check and assume you have root access.
-v Display gcc_select version number.
--version Same as -v.
")
and as an obvious next step, could try issuing "gcc_select foo.bar"
with foo==4 an bar==2 (or something more reasonable from your output
of gcc<TAB><TAB>) and then try to rebuild Sage from scratch (!!!),
i.e. do "make distclean", or erase all former build output manually,
or start over in a new directory straight from the tarball? (Using the
GCC environment variable instead might still not be supported smoothly
enough by all of the Sage distribution components.)
Thanks in advance!
Cheers,
Georg
Samuel Lelievre
Yes, it's there
$ ls -al /usr/bin/gcc*
lrwxr-xr-x 1 root wheel 7 8 May 2010 /usr/bin/gcc -> gcc-4.0
-r-xr-xr-x 1 root wheel 258368 19 Feb 2008 /usr/bin/gcc-3.3
-rwxr-xr-x 1 root wheel 93088 5 Feb 2009 /usr/bin/gcc-4.0
-rwxr-xr-x 1 root wheel 105680 7 Jul 2009 /usr/bin/gcc-4.2
I'm switching to gcc-4.2.1
$ sudo ln -sf /usr/bin/gcc-4.2 /usr/bin/gcc
Done:
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure
--disable-checking --enable-werror --prefix=/usr
--mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin9
--with-gxx-include-dir=/usr/include/c++/4.0.0
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
I'm curious, since XCode 3.1.4 includes both gcc 4.0.1 and 4.2.1,
why it sets by default gcc as an alias to 4.0.1 rather than 4.2.1.
Launching 'make build' again, the build fails on polybori again.
Maybe a build started with gcc 4.0.1 can't finish with 4.2.1...
So start again from scratch: unzip sage-4.7.alpha5 and try
'make' with gcc 4.2.1. I get an error right at the beginning
while testing prerequisites: it says prerequisites are not met,
gcc and g++ are different versions and should be the same.
So, same line for g++:
$ ls -al /usr/bin/g+*
lrwxr-xr-x 1 root wheel 7 8 May 2010 /usr/bin/g++ -> g++-4.0
-r-xr-xr-x 1 root wheel 258368 19 Feb 2008 /usr/bin/g++-3.3
-rwxr-xr-x 1 root wheel 93088 5 Feb 2009 /usr/bin/g++-4.0
-rwxr-xr-x 1 root wheel 105680 7 Jul 2009 /usr/bin/g++-4.2
$ sudo ln -sf /usr/bin/g++-4.2 /usr/bin/g++
$ ls -al /usr/bin/g+*
lrwxr-xr-x 1 root wheel 16 22 Apr 10:51 /usr/bin/g++ -> /usr/bin/g++-4.2
-r-xr-xr-x 1 root wheel 258368 19 Feb 2008 /usr/bin/g++-3.3
-rwxr-xr-x 1 root wheel 93088 5 Feb 2009 /usr/bin/g++-4.0
-rwxr-xr-x 1 root wheel 105680 7 Jul 2009 /usr/bin/g++-4.2
Start again from the freshly unzipped 4.7.alpha5. It's started
working; I'll post when the build completes or fails.
Samuel
Samuel Lelievre
> On 22 Apr., 05:41, Dima Pasechnik wrote:
>> On Apr 22, 2:36 am, Jeroen Demeyer wrote:
>> > On 2011-04-21 14:50, Samuel Lelievre wrote:
>> > > Yes, it's XCode 3.1.4, the latest XCode for Mac OS X 10.5.x.
>> > > XCode 3.2.x or 4.x require Mac OS X 10.6.x.
>>
>> > I'm afraid you're out of luck then. The error message clearly indicates
>> > a bug within gcc itself. Essentially the only solution is compiling a
>> > newer version of gcc (but not version 4.6.0) from scratch. I have no
>> > idea how easy/difficult this is on a Mac.
>>
>> it's pretty much out of the question to use a compiler that does not
>> come with Xcode, or at least
>> ones that are not "Apple build".
>>
>> Samuel, don't you have gcc-4.2.1 installed as a part of Xcode?
>> You can switch to it then.
>
George,
This is what I get with 'gcc<TAB><TAB>', and with 'gcc_select --help':
$ gcc
gcc gcc-4 gcc-4.2 gcc-mp-4.4 gccbug-mp-4.4
gcc-3.3 gcc-4.0 gcc-mp-4.3 gccbug-mp-4.3 gccmakedep
$ gcc_select --help
-bash: gcc_select: command not found
Samuel
Justin C. Walker
On Apr 22, 2011, at 04:10 , Samuel Lelievre wrote:
> 2011-04-22 gsw:
[snip]
>
> This is what I get with 'gcc<TAB><TAB>', and with 'gcc_select --help':
>
> $ gcc
> gcc gcc-4 gcc-4.2 gcc-mp-4.4 gccbug-mp-4.4
> gcc-3.3 gcc-4.0 gcc-mp-4.3 gccbug-mp-4.3 gccmakedep
>
> $ gcc_select --help
> -bash: gcc_select: command not found
For the record, 'gcc_select' (from Apple) is only found on releases of Mac OS X prior to 10.5, I think.
MacPorts has a version of 'gcc_select'. Haven't tried it, though.
I don't think it changes the version that would be used by Xcode. That's usually controlled by build settings.
HTH
Justin
--
Justin C. Walker
Director
Institute for the Enhancement of the Director's Income
--
Fame is fleeting, but obscurity
just drags on and on. F&E
Samuel Lelievre
> On Apr 22, 2011, at 04:10 , Samuel Lelievre wrote:
>> This is what I get with 'gcc<TAB><TAB>', and with 'gcc_select --help':
>>
>> $ gcc
>> gcc gcc-4 gcc-4.2 gcc-mp-4.4 gccbug-mp-4.4
>> gcc-3.3 gcc-4.0 gcc-mp-4.3 gccbug-mp-4.3 gccmakedep
>>
>> $ gcc_select --help
>> -bash: gcc_select: command not found
>
> For the record, 'gcc_select' (from Apple) is only found on releases of Mac OS X prior to 10.5, I think.
>
> MacPorts has a version of 'gcc_select'. Haven't tried it, though.
>
> I don't think it changes the version that would be used by Xcode. That's usually controlled by build settings.
Thanks for this. I changed the version by hand, using 'ln -sf' to change
the aliases /usr/bin/gcc and /usr/bin/g++ to point to 4.2 instead of 4.0.
With gcc & g++ 4.2.1 instead of 4.0.1 (intel Mac, Mac OS X 10.5.8),
the build completed successfully.
$ date -u "+Date: %F %T Z"
Date: 2011-04-22 10:54:21 Z
$ uname -a
Darwin U 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT
2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure
--disable-checking --enable-werror --prefix=/usr
--mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin9
--with-gxx-include-dir=/usr/include/c++/4.0.0
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
$ cd /Applications/sage-4.7.alpha5
$ make build
[snip]
real 196m10.014s
user 172m23.469s
sys 28m29.590s
To install gap, gp, singular, etc., scripts
in a standard bin directory, start sage and
type something like
sage: install_scripts('/usr/local/bin')
at the Sage command prompt.
To build the documentation, run
make doc
Sage build/upgrade complete!
$
Samuel
amaseam
> Dear Sage lovers,
>
> We're releasing Sage 4.7.alpha5.
>
> experiences with this release.
intel iMac, osx 10.6.7
make build: ok
make doc: ok
make ptestlong: error
$ uname -a
Darwin iMac 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16
PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure
--disable-checking --enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin10
--program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
--target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
$ cd /Applications/sage-4.7.alpha5
$ export MAKE="make -j2"
$ export SAGE_PARALLEL_SPKG_BUILD="yes"
$ export SAGE_TIMEOUT=1200
$ export SAGE_TIMEOUT_LONG=5400
$ make ptestlong
[...]
sage -t -long -force_lib devel/sage/sage/groups/matrix_gps/matrix_group.py
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage-main/sage/groups/matrix_gps/matrix_group.py",
line 668:
sage: G.random_element()
Expected:
[2 1 1 1]
[1 0 2 1]
[0 1 1 0]
[1 0 0 1]
Got:
[0 1 1 0]
[1 2 2 2]
[1 1 1 0]
[2 0 1 2]
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage-main/sage/groups/matrix_gps/matrix_group.py",
line 679:
sage: G.random_element()
Expected:
[1 3]
[0 3]
Got:
[4 2]
[1 0]
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage-main/sage/groups/matrix_gps/matrix_group.py",
line 682:
sage: G.random_element()
Expected:
[2 2]
[1 0]
Got:
[4 1]
[0 2]
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage-main/sage/groups/matrix_gps/matrix_group.py",
line 685:
sage: G.random_element()
Expected:
[4 0]
[1 4]
Got:
[2 4]
[2 3]
**********************************************************************
1 items had failures:
4 of 11 in __main__.example_22
***Test Failed*** 4 failures.
For whitespace errors, see the file
/Users/chateau/.sage//tmp/.doctest_matrix_group.py
[...]
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib
devel/sage/sage/groups/matrix_gps/matrix_group.py # 4 doctests failed
----------------------------------------------------------------------
Total time for all tests: 8950.2 seconds
make: *** [ptestlong] Error 128
$
Jeroen Demeyer
> intel iMac, osx 10.6.7
>
> make build: ok
> make doc: ok
> make ptestlong: error
$ ./sage -t -long -force_lib
devel/sage/sage/groups/matrix_gps/matrix_group.py
amaseam
Reproducible it is.
$ cd /Applications/sage-4.7.alpha5
$ ./sage -t -long -force_lib devel/sage/sage/groups/matrix_gps/matrix_group.py
sage -t -long -force_lib "devel/sage/sage/groups/matrix_gps/matrix_group.py"
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage/sage/groups/matrix_gps/matrix_group.py",
line 668:
sage: G.random_element()
Expected:
[2 1 1 1]
[1 0 2 1]
[0 1 1 0]
[1 0 0 1]
Got:
[0 1 1 0]
[1 2 2 2]
[1 1 1 0]
[2 0 1 2]
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage/sage/groups/matrix_gps/matrix_group.py",
line 679:
sage: G.random_element()
Expected:
[1 3]
[0 3]
Got:
[4 2]
[1 0]
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage/sage/groups/matrix_gps/matrix_group.py",
line 682:
sage: G.random_element()
Expected:
[2 2]
[1 0]
Got:
[4 1]
[0 2]
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage/sage/groups/matrix_gps/matrix_group.py",
line 685:
sage: G.random_element()
Expected:
[4 0]
[1 4]
Got:
[2 4]
[2 3]
**********************************************************************
1 items had failures:
4 of 11 in __main__.example_22
***Test Failed*** 4 failures.
For whitespace errors, see the file
/Users/chateau/.sage//tmp/.doctest_matrix_group.py
[136.2 s]
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib "devel/sage/sage/groups/matrix_gps/matrix_group.py"
Total time for all tests: 136.2 seconds
$
Jeroen Demeyer
> 2011-04-22 Jeroen Demeyer:
>> On 2011-04-22 20:54, amaseam wrote:
>>> intel iMac, osx 10.6.7
>>>
>>> make build: ok
>>> make doc: ok
>>> make ptestlong: error
>> Is this error reproducible, i.e. does it appear again when you do
>> $ ./sage -t -long -force_lib
>> devel/sage/sage/groups/matrix_gps/matrix_group.py
>
> Reproducible it is.
First time I see this problem. Any other people with similar machines
to test this? (Intel iMac, osx 10.6.7)
Jeroen.
John H Palmieri
$ uname -a
Darwin jpalmieri538.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
--
John
Dr. David Kirkby
> Dear Sage lovers,
>
> We're releasing Sage 4.7.alpha5.
>
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4.7.alpha5.tar
> == Known issues ==
>
> * Some doctests fail on bsd.math (OS X 10.6 i386), when compiling in
> 64-bit mode due to SAGE64 verbosity. This is #10303.
> * Various packages on various systems do not compile with gcc 4.6.0.
> This will be sorted out during the sage-4.7.1 release cycle.
I'm using gcc 4.6, so the build would fail, but after the updated packages for
rubiks
http://trac.sagemath.org/sage_trac/ticket/11168
and singular
http://trac.sagemath.org/sage_trac/ticket/11084
all doctests passed on OpenSolaris 06/2009.
Perhaps my machine was more busy than usual, but the tests took longer than
usual. Normally they get done in well under 1700 seconds.
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 1753.9 seconds
Dave
Samuel Lelievre
make doc: ok
make testlong: one error in matrix_double_dense.pyx (see below)
and a bunch of "(skipping) -- nodoctest.py file in directory".
$ uname -a
Darwin U 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT
2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5577~1/src/configure
--disable-checking --enable-werror --prefix=/usr
--mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin9
--with-gxx-include-dir=/usr/include/c++/4.0.0
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5577)
$ cd /Applications/sage-4.7.alpha5
$ export SAGE_TIMEOUT=1200
$ export SAGE_TIMEOUT_LONG=5400
$ make testlong
[snip]
sage -t -long -force_lib "devel/sage/sage/matrix/matrix_double_dense.pyx"
**********************************************************************
File "/Applications/sage-4.7.alpha5/devel/sage/sage/matrix/matrix_double_dense.pyx",
line 1390:
sage: V.is_unitary()
Expected:
True
Got:
False
**********************************************************************
1 items had failures:
1 of 19 in __main__.example_31
***Test Failed*** 1 failures.
For whitespace errors, see the file
/Users/samuel/.sage//tmp/.doctest_matrix_double_dense.py
[4.1 s]
[snip]
----------------------------------------------------------------------
The following tests failed:
sage -t -long -force_lib "devel/sage/sage/matrix/matrix_double_dense.pyx"
Total time for all tests: 16902.0 seconds
make: *** [testlong] Error 128
$
Justin C. Walker
I've not seen this. I just finished a full build of a5, with no problems (other than the well-known #9960). I ran the above test by hand in several of the recent alphas and releases, with no errors.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
Experience is what you get
when you don't get what you want.
--------
Rob Beezer
> sage -t -long -force_lib "devel/sage/sage/matrix/matrix_double_dense.pyx"
> **********************************************************************
> File "/Applications/sage-4.7.alpha5/devel/sage/sage/matrix/matrix_double_dense.pyx",
> line 1390:
> sage: V.is_unitary()
> Expected:
> True
> Got:
> False
> **********************************************************************
this is the first mention, have you checked to see if it is
reproducible?
With a Schur decomposition available (#11027, positive review), a more
robust approach to is_unitary is possible (thanks to an idea of Martin
Raum's), which is illustrated in #10848 (is_hermitian) and #11104
(is_normal).
Samuel Lelievre
> On Apr 23, 2:58 am, Samuel Lelievre <samuel.lelie...@gmail.com> wrote:
>> sage -t -long -force_lib "devel/sage/sage/matrix/matrix_double_dense.pyx"
>> **********************************************************************
>> File "/Applications/sage-4.7.alpha5/devel/sage/sage/matrix/matrix_double_dense.pyx",
>> line 1390:
>> sage: V.is_unitary()
>> Expected:
>> True
>> Got:
>> False
>> **********************************************************************
>
> This is likely from #10863, which was merged in 4.7.alpha4. Since
> this is the first mention, have you checked to see if it is
> reproducible?
Yes, I 'cd'-ed to /Applications/sage-4.7.alpha5 and I ran once more
./sage -t -long -force_lib "devel/sage/sage/matrix/matrix_double_dense.pyx"
and it produced the same error.
Kiran Kedlaya
beta (64-bit in my case) with the "no module named crypt" error.
However, I also noticed some problems with the Atlas build. Here's the
tail end; full install log available upon request.
Kiran
---
cp /home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/atlas-3.8.3.p16/
ATLAS-build/lib/libptcblas.a /home/kedlaya/Downloads/sage-4.7.alpha5/
local/lib/.
cp: cannot stat `/home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/
atlas-3.8.3.p16/ATLAS-build/lib/libptcblas.a': No such file or
directory
make[3]: [install_lib] Error 1 (ignored)
cp /home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/atlas-3.8.3.p16/
ATLAS-build/lib/libptf77blas.a /home/kedlaya/Downloads/sage-4.7.alpha5/
local/lib/.
cp: cannot stat `/home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/
atlas-3.8.3.p16/ATLAS-build/lib/libptf77blas.a': No such file or
directory
make[3]: [install_lib] Error 1 (ignored)
cp /home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/atlas-3.8.3.p16/
ATLAS-build/lib/libatlas.so /home/kedlaya/Downloads/sage-4.7.alpha5/
local/lib/.
cp /home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/atlas-3.8.3.p16/
ATLAS-build/lib/libcblas.so /home/kedlaya/Downloads/sage-4.7.alpha5/
local/lib/.
cp /home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/atlas-3.8.3.p16/
ATLAS-build/lib/libf77blas.so /home/kedlaya/Downloads/sage-4.7.alpha5/
local/lib/.
cp /home/kedlaya/Downloads/sage-4.7.alpha5/spkg/build/atlas-3.8.3.p16/
ATLAS-build/lib/liblapack.so /home/kedlaya/Downloads/sage-4.7.alpha5/
local/lib/.
chmod 0644 /home/kedlaya/Downloads/sage-4.7.alpha5/local/lib/
libatlas.so /home/kedlaya/Downloads/sage-4.7.alpha5/local/lib/
liblapack.so \
/home/kedlaya/Downloads/sage-4.7.alpha5/local/lib/
libcblas.so /home/kedlaya/Downloads/sage-4.7.alpha5/local/lib/
libcblas.so
chmod 0644 /home/kedlaya/Downloads/sage-4.7.alpha5/local/lib/
libptcblas.a /home/kedlaya/Downloads/sage-4.7.alpha5/local/lib/
libptf77blas.a
chmod: cannot access `/home/kedlaya/Downloads/sage-4.7.alpha5/local/
lib/libptcblas.a': No such file or directory
chmod: cannot access `/home/kedlaya/Downloads/sage-4.7.alpha5/local/
lib/libptf77blas.a': No such file or directory
make[3]: [install_lib] Error 1 (ignored)
make[3]: Leaving directory `/home/kedlaya/Downloads/sage-4.7.alpha5/
spkg/build/atlas-3.8.3.p16/ATLAS-build'
make[2]: Leaving directory `/home/kedlaya/Downloads/sage-4.7.alpha5/
spkg/build/atlas-3.8.3.p16/ATLAS-build'
ld -L/home/kedlaya/Downloads/sage-4.7.alpha5/local/lib -shared -soname
liblapack.so -o liblapack.so --whole-archive liblapack.a --no-whole-
archive -lc -lm -lgfortran
ld: cannot find -lgfortran
ld -L/home/kedlaya/Downloads/sage-4.7.alpha5/local/lib -shared -soname
libf77blas.so -o libf77blas.so --whole-archive libf77blas.a --no-whole-
archive -lc -lm -lgfortran
ld: cannot find -lgfortran
ATLAS failed to build for the 1-th time, possibly because of a
loaded system, so we will automatically try again up to 4 more times.
Waiting 13 minutes...
real 225m51.708s
user 200m34.570s
sys 4m6.360s
Successfully installed atlas-3.8.3.p16
Now cleaning up tmp files.
Making Sage/Python scripts relocatable...
Making script relocatable
Finished installing atlas-3.8.3.p16.spkg
---
> Dear Sage lovers,
>
> We're releasing Sage 4.7.alpha5.
>
> Source archive:
>
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/sage-4....
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
>
>
> * The 4.7 release cycle is now considered feature-complete. Essentially
> only blocker tickets or trivial patches will be considered for inclusion
> in the next development releases.
> * Ticket #11027 (Schur matrix decomposition over RDF/CDF) was unmerged
> because of doctest failures on various machines.
> * Because of issues with SAGE_SPKG_INSTALL_DOCS and Sphinx,
> the tickets #10826 (numpy), #10827 (cython), #10828 (matplotlib) were
> unmerged.
> == Known issues ==
>
> * Some doctests fail on bsd.math (OS X 10.6 i386), when compiling in
> 64-bit mode due to SAGE64 verbosity. This is #10303.
> * Various packages on various systems do not compile with gcc 4.6.0.
> This will be sorted out during the sage-4.7.1 release cycle.
>
>
> * We closed 188 tickets in this release. For details, see
>
> http://boxen.math.washington.edu/home/release/sage-4.7.alpha5/tickets...
>
> Closed tickets:
>
> #8613: __dir__() / tab completion returns nonexistent attributes
> [Reviewed by Simon King]
> #10994: Bug in permutation_automorphism_group for linear codes [Reviewed
> by Robert Miller]
> #11032: automorphism_group_binary_code crashes Sage when it can't
> allocate enough memory [Reviewed by Robert Miller]
>
> Merged in sage-4.7.alpha5:
>
> #7105: John Palmieri: change search_doc and search_src so the links are
> opened in a new tab/window [Reviewed by Karl-Dieter Crisman]
> #8614: William Stein: Optimize creation of modular symbols spaces by
> speeding up quotienting out by 2-term relations [Reviewed by Alex
> Ghitsa, David Loeffler, John Cremona]
> #8998: William Stein: galois_action on cusps has a bug [Reviewed by John
> Cremona]
> #9028: Andrew Hou, Benjamin Jones: Basic Stats - Standard Deviation
> [Reviewed by Simon Spicer]
> #9094: Robert Bradshaw, Maarten Derickx: is_square and sqrt for
> polynomials and fraction fields [Reviewed by John Cremona, Marco Streng,
> Robert Bradshaw]
> #9109: Florent Hivert: Fast cython class for maps between finite sets.
> [Reviewed by Mike Hansen, Nicolas M. Thiéry]
> #9371: Jamie Weigandt, Aly.deines: Implement E.two_torsion_rank() over
> number fields [Reviewed by John Cremona, Gagan Sekhon]
> #9497: Martin Albrecht, John Palmieri: Fix the Singular spkg so it can
> take advantage of building in parallel [Reviewed by David Kirkby]
> #9705: William Stein: trouble with long lines in notebook magma mode
> [Reviewed by Martin Raum]
> #9969: Fredrik Johansson: Update extension code for mpmath-0.17
> [Reviewed by François Bissey]
> #10055: Thierry Monteil: Fix typos and formatting in
> sage/combinat/words/notes/historic.txt and rename it history.txt
> [Reviewed by Sébastien Labbé, Jeroen Demeyer]
> #10109: Jeroen Demeyer: Document sig_on() in the developer manual
> [Reviewed by Volker Braun]
> #10124: Douglas McNeil: Graph drawing has issues with edge labels
> [Reviewed by Nathann Cohen]
> #10601: Simon Spicer: QuaternionAlgebra constructor does not work for
> python int [Reviewed by Rob Beezer]
> #10761: Simon Spicer: Numerical approximation of an algebraic number
> raises a ValueError [Reviewed by Rob Beezer]
> #10794: Rob Beezer: QR decomposition for matrices over exact rings
> [Reviewed by Simon Spicer]
> #10796: Robert Bradshaw, Karl-Dieter Crisman: Platonic solid
> constructors scale and translate in the wrong order. [Reviewed by
> Karl-Dieter Crisman, Robert Bradshaw]
> #10799: Miguel Marco: Solved the problem to compute resultants on
> certain variable orders [Reviewed by Simon Spicer]
> #10832: John Cremona: bug in simon_two_descent() [Reviewed by Chris
> Wuthrich]
> #10840: John Cremona: bug in saturation for elliptic curves over Q
> [Reviewed by Gagan Sekhon]
> #10847: Jason Grout: matrix_plot can now plot subdivisions [Reviewed by
> Karl-Dieter Crisman, John Palmieri]
> #10858: Johan Bosman: segfault when multiplying 0x0 dense matrix with a
> vector. [Reviewed by Maarten Derickx]
> #10865: Minh Van Nguyen, Mariah Lenox: update copyright years to include
> 2011 [Reviewed by Minh Van Nguyen, Mariah Lenox]
> #10905: Nathann Cohen: shortest path all pairs through BFS computations.
> [Reviewed by Yann Laigle-Chapuy]
> #10933: Maarten Derickx: time of magma command fails inside function
> [Reviewed by Martin Raum]
> #10934: John Palmieri: is_maximal is broken [Reviewed by Simon Spicer]
> #10939: Nicolas M. Thiéry: Relabel a graph according to a bijective
> function [Reviewed by Nathann Cohen]
> #10986: François Bissey: building ecl fails in case the installed etags
> is actually exuberant-ctags [Reviewed by Harald Schilly, Simon King]
> #10987: Martin Raum: Add optional arguement to decomposition_of_subspace
> making restrict not check the subspace [Reviewed by Rob Beezer]
> #11007: William Stein: heegner points -- a nonsquarefree case [Reviewed
> by Jennifer Balakrishnan]
> #11019: Martin Albrecht: BooleanPolynomial.lex_lead() shouldn't crash on
> zero [Reviewed by Alexander Dreyer]
> #11033: Robert Miller: fixes and improvements to automorphism groups of
> linear codes [Reviewed by David Joyner]
> #11046: Nathann Cohen: Some comments in the code of SparseGraph
> [Reviewed by Robert Miller]
> #11128: Sébastien Labbé: Limit case bug for conjugate_position in words
> [Reviewed by Alexandre Blondin Massé]
> #11136: David Kirkby: Upgrade sqlite to the newest upstream release
> (3.7.5) [Reviewed by Mariah Lenox, François Bissey]
> #11141: John Palmieri: update SAGE_ROOT/local/bin/.hgignore [Reviewed by
> David Kirkby]
> #11156: Nicolas M. Thiéry: sage.misc.sage_unittest.InstanceTester should
> call its base's __init__ [Reviewed by François Bissey]
> #11163: William Stein: documentation of p-adic L-function
> order_of_vanishing is very wrong [Reviewed by David Loeffler]
Rob Beezer
> As was the case for alpha4, this fails to build under the Ubuntu 11.04
> beta (64-bit in my case) with the "no module named crypt" error.
put up a proposed patch to the Python spkg at:
http://trac.sagemath.org/sage_trac/ticket/11243
It could use a review from somebody knowledgeable in such things, so
we don't get a flood of problems when Ubuntu 11.04 is released
(soon?).
Rob
leif
April 28th (Thursday).
-Leif
Rob Beezer
wrote:
>
> ./sage -t -long -force_lib "devel/sage/sage/matrix/matrix_double_dense.pyx"
>
> and it produced the same error.
Thanks for the do-over. Either the SVD is not building a unitary
matrix for V, or the check on V is failing. Or something completely
different. Default tolerance is 1e-12 for zero entries and I'm seeing
values more like 1e-16. So I'd like to understand what's going on
with your setup. Could you run some test code that expands the
example that is failing?
http://pastebin.com/S549jpWU
has 10 lines of code - you should be able to just paste it into a Sage
terminal session all at once. I've included what I would expect, just
for completeness.
Maybe best to paste the results into a similar pastebin session
instead of letting email/groups mangle it too badly.
Thanks for your help chasing this one down.
Rob
David Kirkby
I've looked at that and found it needed a bit of work, as it used the
command 'lsb_release` which is not portable - some Linux systems have
it, some do not.
It does need review, though I have had to accept what Jan says works
on Ubuntu 11.04. But the package should ensure the crypt module is
installed, irrespective of the platform.
Samuel Lelievre
Rob Beezer
> Here goes:http://pastebin.com/vvx1tvbW
Thanks, Samuel. Looks like the V matrix has a column of zeros (the
last one) which clearly prevents it from being unitary. So this looks
to me like erroneous output from the SVD method, which wraps the numpy
method, and has been in Sage for at least three years now.
Can you hang onto the version of Sage you have there? I might try to
isolate this to numpy itself, but will require running it on your
setup, I'd imagine. We can take that off-list or run it on a Trac
ticket.
Jeroen - how do you want to handle this one? At a minimum, I can open
a ticket for this and pursue it, perhaps tracking it down to numpy.
Seems odd it is only failing on this one combination of compiler and
hardware. I think #10863 is just exposing a flaw somewhere else.
Rob
Jeroen Demeyer
> Jeroen - how do you want to handle this one? At a minimum, I can open
> a ticket for this and pursue it, perhaps tracking it down to numpy.
is possible, it could still be in sage-4.7.
> Seems odd it is only failing on this one combination of compiler and
> hardware.
Yes, very strange (and annoying) indeed...
Jeroen.
Rob Beezer
> That would be great if that would be possible. If a quick and easy fix
> is possible, it could still be in sage-4.7.
"pure" `NumPy` and post to their discussion list if it seems that the
root of the problem lies there.
Discussion will move to:
http://trac.sagemath.org/sage_trac/ticket/11248