We're releasing Sage 5.0.beta13.
Source archive:
http://boxen.math.washington.edu/home/release/sage-5.0.beta13/sage-5.0.beta13.tar
Upgrade path:
http://boxen.math.washington.edu/home/release/sage-5.0.beta13/sage-5.0.beta13/
The source and upgrade path can also be found on the mirror network
(you might need to wait a while before the mirrors are synchronized):
http://www.sagemath.org/download-latest.html
Please build, test, and report! We'd love to hear about your
experiences with this release.
== Notes ==
* This release of Sage contains a GCC (GNU Compiler Collection) package.
This includes compilers for C, C++ and Fortran. GCC is not always
built, whether or not it is built is determined automatically. You
can use the environment variable SAGE_INSTALL_GCC to override the
default. Set SAGE_INSTALL_GCC=no if you don't want to build GCC or
SAGE_INSTALL_GCC=yes to force building GCC.
* With the addition of GCC, the gfortran binaries for OS X have been
removed. gfortran is part of GCC and will be built from source.
* The moin moin Wiki has been removed from Sage, saving 28MB in the
compressed tarball.
== Tickets ==
* We closed 447 tickets in this release. For details, see
http://boxen.math.washington.edu/home/release/sage-5.0.beta13/tickets.html
Closed tickets:
#2102: add incoming/outgoing wrappers to HG objects (like hg_sage)
[Reviewed by Mike Hansen]
#4780: relative number field constructor -- error message when given
poly of degree < 1 is bad [Reviewed by Mike Hansen, David Loeffler]
#7038: ratpoints 2.1.2.p2 ignores CC and uses gcc whatever [Reviewed by
Leif Leonhardy]
#8125: problem with "text" in matplotlib [Reviewed by John Palmieri]
#11702: interfaces/magma.py test fails [Reviewed by Marco Streng, David
Loeffler]
#11875: Correct general brokenness of Farey symbols [Reviewed by David
Loeffler]
#12004: copying a linear program using Coin solver consumes enormous
amounts of memory [Reviewed by Nathann Cohen]
Merged in sage-5.0.beta13:
#9563: Mike Hansen: Remove the English-language tutorial's Makefile
[Reviewed by Jeroen Demeyer]
#12011: Jeroen Demeyer, John Palmieri: cvxopt: fix illegal BLAS call and
fix Solaris build [Reviewed by Jeroen Demeyer, John Palmieri]
#12112: John Palmieri, Jeroen Demeyer: Update the prereq script
[Reviewed by Jeroen Demeyer, David Kirkby]
#12220: John Perry, Nathann Cohen: Updated CBC spkg [Reviewed by John
Perry, Nathann Cohen]
#12369: Jeroen Demeyer: Add a gcc package [Reviewed by Simon King]
#12515: Jeroen Demeyer: Upgrade mpc and make it a standard package
[Reviewed by Jean-Pierre Flori, Volker Braun]
#12576: John Palmieri: OS X Lion: don't require setting SAGE_PORT
[Reviewed by Jeroen Demeyer]
#12613: John Palmieri: Add option "-c" to sage-spkg to run the
test-suite [Reviewed by Jeroen Demeyer]
#12631: Jeroen Demeyer: Get rid of spkg/base/dir-0.1-install [Reviewed
by John Palmieri]
#12655: Alexander Dreyer: Update PolyBoRi to release 0.8.1 [Reviewed by
Martin Albrecht, Jeroen Demeyer, Leif Leonhardy]
#12668: David Loeffler: Delete sage/rings/coerce_python.py [Reviewed by
Jeroen Demeyer]
#12713: John Palmieri: Excise MoinMoin [Reviewed by Jeroen Demeyer]
#12784: John Palmieri: Add comment to deps explaining dependency of
cvxopt on matplotlib [Reviewed by Karl-Dieter Crisman]
#12799: Alexander Dreyer: Fix PolyBoRi's dependencies in
`module_list.py` [Reviewed by Leif Leonhardy]
#12805: John Palmieri: Do not create SAGE_TESTDIR/tmp [Reviewed by Leif
Leonhardy]
#12814: Jeroen Demeyer: Add prereq-0.9-install to .hgignore [Reviewed by
John Palmieri]
**********************************************************************
File "/Users/Starx/sage-dev/devel/sage-main/sage/schemes/elliptic_curves/modular_parametrization.py",
line 17:
sage: phi = EllipticCurve('11a1').modular_parametrization()
Exception raised:
Traceback (most recent call last):
File "/Users/Starx/sage-dev/local/bin/ncadoctest.py", line 1231,
in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/Users/Starx/sage-dev/local/bin/sagedoctest.py", line 38,
in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/Users/Starx/sage-dev/local/bin/ncadoctest.py", line 1172,
in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_0[2]>", line 1, in <module>
phi = EllipticCurve('11a1').modular_parametrization()###line 17:
sage: phi = EllipticCurve('11a1').modular_parametrization()
File "/Users/Starx/sage-dev/local/lib/python/site-packages/sage/schemes/elliptic_curves/constructor.py",
line 301, in EllipticCurve
return ell_rational_field.EllipticCurve_rational_field(x)
File "/Users/Starx/sage-dev/local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_rational_field.py",
line 198, in __init__
X = sage.databases.cremona.CremonaDatabase()[label]
File "/Users/Starx/sage-dev/local/lib/python/site-packages/sage/databases/cremona.py",
line 1363, in CremonaDatabase
_db = LargeCremonaDatabase(name)
File "/Users/Starx/sage-dev/local/lib/python/site-packages/sage/databases/cremona.py",
line 1119, in __init__
+ 'not appear to be a valid SQL Cremona database.')
RuntimeError: Database at
/Users/Starx/sage-dev/data//cremona/cremona.db does not appear to be a
valid SQL Cremona database.
**********************************************************************
The file /Users/Starx/sage-dev/data/cremona/cremona.db does exist (not
sure why there's a double slash in the error message...) but it is
empty.
-Jim
> --
> 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.
>
--
Die Dunkelheit... leitet die Musik.
Die Musik... leitet die Seele.
The file should probably not exist (since it should only exist if you
have installed the optional cremona database). It was probably created
by accident at some point (one of the optional doctests will do this).
See http://trac.sagemath.org/sage_trac/ticket/12341.
--
Andrew
The failure is in the gcc spkg. I found that compiling gcc on recent
versions of Ubuntu is a bit tricky, since they are now using this
"multiarch" stuff. I forget which package you need to install, but I
tried to compile gcc on my own, and eventually gave up.
On my Ubuntu 10.04 machine, gcc didn't get built, even though it has
4.4.3; I wonder why your build decided to make gcc.
Dan
--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------
[/usr/include/]bits/predefs.h is part of the GNU C library, i.e., the
Ubuntu package libc6-dev.
Wonder how you would be able to compile anything without it, as most
headers include parts from bits/*; probably you just have to reinstall it.
> I am somewhat surprised that gcc is being built at all since I have
> gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3). However the install
> log claims: Installing GCC because your 'gcc' is not so recent.
No idea. Smells like your Ubuntu / GCC installation is quite broken.
I've successfully built beta13 on Ubuntu 10.04.4 LTS x86_64 with the
native 4.4.3 GCC and SAGE_INSTALL_GCC=yes.
On Precise (12.04 beta), I did have some trouble (with
SAGE_INSTALL_GCC=yes), partially apparently due to GCC itself, or how it
is configured in the spkg, partially due to Ubuntu's multi-arch setup.
The latter can be solved (on x86_64) by e.g. creating symbolic links for
/usr/x86_64-linux-gnu/crt?.o in /usr/lib/.
Note that Ubuntu's current [broken, non-FSF] GCC 4.6.3-1ubuntu3 won't
build MPFR (a prerequisite for GCC) with '-O3', and won't build Singular
with '-O3' (in CPPFLAGS) either. The former issue is already fixed, but
the fix hasn't been committed (and hence not released) yet.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
Building beta13 on my Ubuntu 11.10 machine is also failing. I see that
SAGE_ROOT/spkg/install distrusts any gcc version 4.6.1, which is what I
have.
I've attached the log. Based on my experiences getting gcc to build on
recent versions of Ubuntu, I think we should disable that check in
spkg/install on Ubuntu. Comments?
Please create a file "errno.c" containing just:
#include <errno.h>
Then do
$ gcc -v -E errno.c -o errno.i
and send me the output of that command as well as the resulting errno.i
file.
The problem is gcc isn't looking in the right places in Ubuntu: see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48879. I've set
C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu and the build continued,
although it failed when trying to link crti.o, which required setting
LIBRARY_PATH; see
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/738098. I have
gcc building right now, we'll see if it finishes.
Instead of disabling the check, we may just need to set a bunch of
variables so gcc and friends find everything.
I wouldn't /generally/ disable it on Ubuntu (maybe all Debians?), but
the message is plain wrong, and it would certainly be annoying if Sage
did per default build GCC on the [currently] latest stable version of
Ubuntu, not to mention it failing while trying to.
Note that Ubuntu's GCCs are quite different to those released by the FSF
(and more recent than the version triplet suggests), so at least it
doesn't make sense to use the output of `gcc -dumpversion` there alone.
[I have to admit I haven't looked at the test in the prereq script, and
OTOH cannot tell what issues we had with GCC 4.6.1 on which platforms.]
I propose to simply *not* install GCC when this multiarch situation is
detected. I think it will be a lot easier than patching GCC to deal
with it.
See #12825.
The gcc spkg built successfully with the following variables set:
C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu
CPLUS_INCLUDE_PATH=/usr/include/x86_64-linux-gnu
(as described in the gcc bugzilla link above), and
LIBRARY_PATH==/usr/lib/x86_64-linux-gnu
(as described in the Launchpad link)
On 32-bit systems, it seems like we'll need "i386", of course.
Here's some information on Debian/Ubuntu's multiarch setup, which they
acknowledge breaks a lot of traditional assumptions about paths, but
seems to solve a lot of problems:
http://wiki.debian.org/Multiarch and https://wiki.ubuntu.com/MultiarchSpec
I will test again to make sure I didn't have anything else in the
environment influencing things.
That's a known problem which should be fixed by #11616.
:-) This time took me three attempts to get a segfault-free ATLAS
library on a 2nd generation Core i5 (with AVX).
I first got the "usual" three segfaults in three files, all in the same
ATLAS function, then I got a different one (in a single file, different
ATLAS function); after building it a third time, ptestlong passed all tests.
On the same machine, Ubuntu 12.04 beta x86_64, in a build with
SAGE_INSTALL_GCC=yes, I get a doctest error presumably due to numeric noise.
After over six hours, it's not finished. Usually a complete build takes
about 90 minutes. Right now, it's stuck on:
ibtool: link: g++ -g -O2 -frounding-math
-I/scratch/sage-5.0.beta13/local/include -W -Wall -o .libs/mipproblem3
mipproblem3.o -L/scratch/sage-5.0.beta13/local/lib
../../utils/libppl_utils.a ../../tests/libppl_tests.a
../../src/.libs/libppl.so /scratch/sage-5.0.beta13/local/lib/libgmpxx.so
/scratch/sage-5.0.beta13/local/lib/../lib64/libstdc++.so -lm
/scratch/sage-5.0.beta13/local/lib/libgmp.so -Wl,-rpath
-Wl,/scratch/sage-5.0.beta13/local/lib -Wl,-rpath
-Wl,/scratch/sage-5.0.beta13/local/lib/../lib64
libtool: link: g++ -g -O2 -frounding-math
-I/scratch/sage-5.0.beta13/local/include -W -Wall -o
.libs/ascii_dump_load1 ascii_dump_load1.o
-L/scratch/sage-5.0.beta13/local/lib ../../utils/libppl_utils.a
../../tests/libppl_tests.a ../../src/.libs/libppl.so
/scratch/sage-5.0.beta13/local/lib/libgmpxx.so
/scratch/sage-5.0.beta13/local/lib/../lib64/libstdc++.so -lm
/scratch/sage-5.0.beta13/local/lib/libgmp.so -Wl,-rpath
-Wl,/scratch/sage-5.0.beta13/local/lib -Wl,-rpath
-Wl,/scratch/sage-5.0.beta13/local/lib/../lib64
There is an "as" process taking up nearly 3 gigabytes of RAM. I don't
quite think it's stuck, but I've never seen this behavior when building
Sage. I'll leave my system swapping overnight (it's late here) and we'll
see if it makes it through.
In any case, the gcc spkg and friends do not seem to be working well on
recent versions of Ubuntu.
I had a similar problem with PPL's mipproblem1 IIRC (with
SAGE_CHECK=yes, and *without* the GCC spkg), where g++ consumed about 5
GB, and afterwards the assembler about 7(!) GB on an asm file of ~1 GB.
(Don't recall right now which GCC exactly that was, and with which
compiler flags; but I think I reported that here on sage-release as well.)
I dropped this on my OS X 10.7.x laptop, didn't type anything special,
typed "make ptestlong", and came back later to see "All tests
passed!". I.e., it built perfectly.
Note that I've upgraded both the OS and XCode to the latest released
version on this laptop. I think this is reasonable to require by
anybody building Sage from source on OS X 10.7, given that XCode is
free.
> --
> 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.
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Ah, I see. That was with my own build of [FSF] GCC 4.6.3 (with PPL 0.12
and CLooG 0.15.11) on Ubuntu 12.04 (and mipproblem1), presumably with
'-march=native -O3 ...', beta11 thread on April 2nd.
Haven't experienced such with the "same" compiler constellation on
Ubuntu 10.04.4 when I built Sage with SAGE_CHECK=yes a while ago.
...and nine hours after *that*, it was still working. I killed it.
That was on a quad-core Core 2 machine with 4 gigs of RAM; I'm now
trying on an Atom netbook with only a gigabyte of RAM. We'll see what
happens there.
On debian-squeeze amd64 I get the following errors when calling "make"
to build sage:
/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/bin/ATLrun.sh
/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/tune/sysinfo
xL1 64
Illegal instruction
make[7]: *** [RunL1] Fehler 132
make[7]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/tune/sysinfo'
xsyssum:
/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/../src//tune/sysinfo/GetSysSum.c:47:
GetL1CacheSize: Assertion `system(ln) == 0' failed.
make[6]: ***
[/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/include/atlas_ssysinfo.h]
Abgebrochen
make[6]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/tune/sysinfo'
make[5]: ***
[/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/include/atlas_ssysinfo.h]
Fehler 2
make[5]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/src/auxil'
make[4]: *** [IStage1] Fehler 2
make[4]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/bin'
ERROR 437 DURING CACHESIZE SEARCH!!. CHECK INSTALL_LOG/Stage1.log FOR
DETAILS.
make[4]: Entering directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/bin'
cd
/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build
; make -j1 error_report
make[5]: Entering directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build'
make -j1 -f Make.top error_report
make[6]: Entering directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build'
uname -a 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
gcc -v 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8)
gcc -V 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
gcc: '-V' option must have argument
make[6]: [error_report] Fehler 1 (ignoriert)
gcc --version 2>&1 >> bin/INSTALL_LOG/ERROR.LOG
tar cf error_Corei264SSE3.tar Make.inc bin/INSTALL_LOG/*
gzip --best error_Corei264SSE3.tar
mv error_Corei264SSE3.tar.gz error_Corei264SSE3.tgz
make[6]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build'
make[5]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build'
make[4]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build/bin'
Error report error_<ARCH>.tgz has been created in your top-level ATLAS
directory. Be sure to include this file in any help request.
cat: ../../CONFIG/error.txt: Datei oder Verzeichnis nicht gefunden
cat: ../../CONFIG/error.txt: Datei oder Verzeichnis nicht gefunden
IN STAGE 1 INSTALL: SYSTEM PROBE/AUX COMPILE
make[3]: *** [build] Fehler 255
make[3]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build'
make[2]: *** [build] Fehler 2
make[2]: Leaving directory
`/local/data/krenn/sage-dev/sage-5.0.beta13/spkg/build/atlas-3.8.4.p1/ATLAS-build'
> Dear Sage lovers,
>
> We're releasing Sage 5.0.beta13.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.0.beta13/sage-5.0.beta13.tar
Built from scratch on Mac OS X, 10.6.8 (Dual 6-core Xeon). "make build" and "make doc" completed w/o problems. "Make ptestlong" had one repeatable error:
sage -t --long -force_lib devel/sage/sage/rings/complex_mpc.pyx # Killed/crashed
Also got the "directory not empty" problem, due to the above failure. If I run this test standalone, it completes successfully, but always fails if I do the full make.
Justin
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
When LuteFisk is outlawed,
Only outlaws will have LuteFisk
--------
Daniel
Did you try again (i.e., to build ATLAS, which typing 'make' of course
would also trigger)?
It's not unusual that you get 'Illegal instruction' errors when building
ATLAS (as it just tries a lot), but usually these are non-fatal, i.e.,
get ignored.
More information on your CPU would probably also be helpful.
[And you could search sage-release for similar issues as well... ;-) ]
-leif
For example
https://groups.google.com/group/sage-release/browse_thread/thread/0f779465055c9162/092d94c3266f50c0#092d94c3266f50c0
: Try setting SAGE_ATLAS_ARCH.
Or, if all else fails, (install and) use a system-wide ATLAS library to
build Sage, by setting SAGE_ATLAS_LIB.
(See
http://sagemath.org/doc/installation/source.html#environment-variables
for documentation on both of these environment variables.)