sage-5.0.rc0 released

[Jeroen Demeyer]

Dear Sage lovers,

We're releasing Sage 5.0.rc0.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0/

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.

== Tickets ==

* We closed 500 tickets in this release. For details, see

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/tickets.html

Closed tickets:

#2732: cython in Debian build doesn't have the right include paths
[Reviewed by Jeroen Demeyer]
#5943: Sage 3.4.2.a0: len(prime_range(2^50)) segfaults [Reviewed by
Michael Orlitzky, Keshav Kini, Volker Braun]
#11844: Race condition in building MPIR/yasm [Reviewed by Leif Leonhardy]
#12315: OS X Lion: pari fails self tests [Reviewed by John Palmieri]
#12319: OS X Lion: gsl fails self tests [Reviewed by John Palmieri]
#12424: OS X Lion: symmetrica doesn't work [Reviewed by John Palmieri]
#12765: MPIR doesn't compile with GCC-4.7.0 on ia64 [Reviewed by Jeroen
Demeyer]
#12782: When building GCC, build MPIR without the C++ interface
[Reviewed by Jeroen Demeyer]

Merged in sage-5.0.rc0:

#5859: Michael Orlitzky: sage -coverageall fails on directories with
zero tests [Reviewed by André Apitzsch]
#8119: Robert Bradshaw: Rename change the hash value of some objects
[Reviewed by Florent Hivert, Nicolas M. Thiéry, Nicolas Borie]
#11616: Leif Leonhardy, Jeroen Demeyer: Upgrade MPIR to a more recent
upstream release [Reviewed by Jeroen Demeyer, Leif Leonhardy, Volker Braun]
#12272: Jeroen Demeyer: More # long time additions [Reviewed by Georg S.
Weber]
#12812: Andrey Novoseltsev: Bug in summation of toric divisors [Reviewed
by Volker Braun]
#12830: Leif Leonhardy: Work around GCC 4.7.0 bug on ia64 and improve
the GMP-ECM spkg [Reviewed by Jeroen Demeyer]
#12833: Nathann Cohen: Crashes and doctests problems with Gurobi
[Reviewed by John Perry]
#12837: Leif Leonhardy: MPFR doesn't compile with GCC-4.7.0 on ia64
[Reviewed by Volker Braun]
#12857: Jeroen Demeyer: Split off Graphics class from plot.py [Reviewed
by Benjamin Jones, Florent Hivert]
#12888: David Coudert: Set new default parameters for RandomGNP
[Reviewed by Nathann Cohen]

[Nicu Tofan]

Well, on my machine is eating all my memory (I believe is near the end, since the log file is already 24 MB).

I have attached the tree of processes and the command used to start each one. As it is there for a while, it may be a GCC bug .

Ubuntu 11.10 - 64-bit
4 GB memory

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
CPU socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 23
Stepping: 10
CPU MHz: 1600.000
BogoMIPS: 5649.14
L1d cache: 32K
L1i cache: 32K
L2 cache: 3072K
NUMA node0 CPU(s): 0,1

Nick

[Franco Saliola]

On Wed, May 2, 2012 at 3:02 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.0.rc0.
>

> Please build, test, and report!  We'd love to hear about your
> experiences with this release.

Same doctest errors with 'make ptest' as for beta14:

$ uname -a
Darwin lacim-macpro-02 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7
16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64

For details:
https://groups.google.com/d/msg/sage-release/_wQyG4AHkB0/18l-HeIUGp0J

Franco

--

[Benjamin Jones]

On Wed, May 2, 2012 at 2:02 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Dear Sage lovers,
>
> We're releasing Sage 5.0.rc0.
>
> Source archive:
>
> http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0.tar
>
> Upgrade path:
>
> http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0/
>
> 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.
>

Sage-5.0.rc0 builds and passes all tests (make ptestlong) on my fedora
16 x86_64 machine:

> uname -a
Linux kimchi.homenetwork 3.3.2-6.fc16.x86_64 #1 SMP Sat Apr 21
12:43:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Also, regarding #12857, I looked through the live documentation on 2D
/ 3D plotting and everything looks good, as expected.

--
Benjamin Jones

[R. Andrew Ohana]

Ok, finished building + testing on my Funtoo x86_64 install w/ sandy
bridge and gcc-4.6.2:

The following tests failed:

sage -t --long -force_lib devel/sage/sage/interfaces/expect.py # 1
doctests failed
sage -t --long -force_lib devel/sage/sage/tests/cmdline.py # 2 doctests failed
sage -t --long -force_lib devel/sage/sage/modular/modsym/ambient.py
# Killed/crashed
sage -t --long -force_lib
devel/sage/sage/modular/hecke/hecke_operator.py # Killed/crashed
sage -t --long -force_lib
devel/sage/sage/modular/hecke/ambient_module.py # Killed/crashed


I haven't really looked into the failures yet other than the cmdline
ones. IPython complains about my ipythonrc. This complaint goes away
if I let sage's copy of ipython (0.10.2) make its own dot_ipython
folder, instead of using my system one, which is generated by my
system install (0.12.1) that I frequently use. The other failure is
regarding a hg extension I have, so that is probably not the fault of
sage.

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org



--
Andrew

[Anthony David]

On Wed, May 2, 2012 at 5:02 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

Dear Sage lovers,

We're releasing Sage 5.0.rc0.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0/

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.

Build successful on Fedora 17

LSB Version:    :core-4.0-amd64:core-4.0-noarch

Distributor ID: Fedora

Description:    Fedora release 16 (Verne)

Release:        16

Codename:       Verne

Only env variables were set for parallel build

Subsequent:

 

./sage -testall -long

All tests passed!

Total time for all tests: 7085.3 seconds

[Jan Groenewald]

Hi

On 2 May 2012 09:02, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0.tar

Please build, test, and report!  We'd love to hear about your
experiences with this release.

make -j3 ptestlong on Ubuntu 12.04:

----------------------------------------------------------------------
All tests passed!
Total time for all tests: 3051.5 seconds
0 jan@snapperkob:~/src/sage-source-builds/sage-5.0.rc0$uname -a
Linux snapperkob 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
0 jan@snapperkob:~/src/sage-source-builds/sage-5.0.rc0$lsb_release -d
Description:    Ubuntu 12.04 LTS
0 jan@snapperkob:~/src/sage-source-builds/sage-5.0.rc0$grep name /proc/cpuinfo
model name      : Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
model name      : Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz


Regards,
Jan

--
  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^

[Anthony David]

On Wed, May 2, 2012 at 5:02 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

Dear Sage lovers,

We're releasing Sage 5.0.rc0.

Source archive:

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0.tar

Upgrade path:

http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0/

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.

Built successfully on i386/i686

LSB Version:    core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch

Distributor ID: Ubuntu

Description:    Ubuntu 11.10

Release:        11.10

Codename:       oneiric

Only  env variables set:

MAKE=make -j2

SAGE_PARALLEL_SPKG_BUILD=yes

All ./sage -testall -long passed except:

 sage -t  -long -force_lib "devel/sage/sage/misc/randstate.pyx" # Time out

        sage -t  -long -force_lib "devel/sage/sage/interacts/debugger.py" # Time out

        sage -t  -long -force_lib "devel/sage/sage/interfaces/expect.py" # Time out

        sage -t  -long -force_lib "devel/sage/sage/interfaces/sage0.py" # Time out

        sage -t  -long -force_lib "devel/sage/sage/interfaces/psage.py" # Time out

        sage -t  -long -force_lib "devel/sage/sage/tests/startup.py" # Time out

[Henry de Valence]

On Wed, May 2, 2012 at 3:02 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Please build, test, and report!  We'd love to hear about your
> experiences with this release.

Running ./sage -testall -long, I get:

<snip>
----------------------------------------------------------------------
The following tests failed:


sage -t -long -force_lib
"devel/sage/doc/en/installation/source.rst" # Time out
sage -t -long -force_lib "devel/sage/sage/misc/sagedoc.py"
sage -t -long -force_lib
"devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" # Time
out
Total time for all tests: 68027.9 seconds
Please see /home/hdevalence/.sage//tmp/test.log for the complete log
from this test.

The test that didn't time out but just failed has the following description in
the log file:


sage -t -long -force_lib "devel/sage/sage/misc/sagedoc.py"·
**********************************************************************
File "/home/hdevalence/code/sage-5.0.rc0/devel/sage/sage/misc/sagedoc.py",
line 22:
sage: for line in open(docfilename):
if "#sage.symbolic.expression.Expression.N" in line:
print line
Exception raised:
Traceback (most recent call last):
File "/home/hdevalence/code/sage-5.0.rc0/local/bin/ncadoctest.py",
line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/hdevalence/code/sage-5.0.rc0/local/bin/sagedoctest.py",
line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/home/hdevalence/code/sage-5.0.rc0/local/bin/ncadoctest.py",
line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_0[3]>", line 1, in <module>
for line in open(docfilename):###line 22:
sage: for line in open(docfilename):
IOError: [Errno 2] No such file or directory:
'/home/hdevalence/code/sage-5.0.rc0/devel/sage/doc/output/html/en/reference/sage/symbolic/expression.html'
**********************************************************************
File "/home/hdevalence/code/sage-5.0.rc0/devel/sage/sage/misc/sagedoc.py",
line 576:
sage: 'abvar/homology' in _search_src_or_doc('doc', 'homology',
'variety', interact=False) # long time (4s on sage.math, 2012)
Expected:
True
Got:
False
**********************************************************************
2 items had failures:
1 of 5 in __main__.example_0
1 of 8 in __main__.example_8
***Test Failed*** 2 failures.
For whitespace errors, see the file /home/hdevalence/.sage//tmp/sagedoc_25648.py
[518.5 s]

Cheers,
Henry de Valence.

[John H Palmieri]

On Friday, May 4, 2012 12:27:33 PM UTC-7, Henry de Valence wrote:

On Wed, May 2, 2012 at 3:02 AM, Jeroen Demeyer wrote:
> Please build, test, and report!  We'd love to hear about your
> experiences with this release.

Running ./sage -testall -long, I get:

What sort of machine, OS, etc.? 

 

<snip>
----------------------------------------------------------------------
The following tests failed:


        sage -t  -long -force_lib
"devel/sage/doc/en/installation/source.rst" # Time out
        sage -t  -long -force_lib "devel/sage/sage/misc/sagedoc.py"
        sage -t  -long -force_lib
"devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" # Time
out
Total time for all tests: 68027.9 seconds
Please see /home/hdevalence/.sage//tmp/test.log for the complete log
from this test.

The test that didn't time out but just failed has the following description in
the log file:

The ensuing error messages make it look like the documentation didn't build. Is that true?

--
John

[Henry de Valence]

On Fri, May 4, 2012 at 4:59 PM, John H Palmieri <jhpalm...@gmail.com> wrote:
>
>
> On Friday, May 4, 2012 12:27:33 PM UTC-7, Henry de Valence wrote:
>>
>> On Wed, May 2, 2012 at 3:02 AM, Jeroen Demeyer wrote:
>> > Please build, test, and report!  We'd love to hear about your
>> > experiences with this release.
>>
>> Running ./sage -testall -long, I get:
>
>
> What sort of machine, OS, etc.?

The machine is an EEE PC X101 (Intel Atom N435 @1.33 GHz, 2 GB RAM)
running 64-bit Debian Squeeze. But Sage is on a microSD card instead of on
the internal SSD, because with an 8GB SSD, there's not a lot of room for
multiple Sage installs + all the system stuff.

>
>>
>> <snip>
>> ----------------------------------------------------------------------
>> The following tests failed:
>>
>>
>>         sage -t  -long -force_lib
>> "devel/sage/doc/en/installation/source.rst" # Time out
>>         sage -t  -long -force_lib "devel/sage/sage/misc/sagedoc.py"
>>         sage -t  -long -force_lib
>> "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" # Time
>> out
>> Total time for all tests: 68027.9 seconds
>> Please see /home/hdevalence/.sage//tmp/test.log for the complete log
>> from this test.
>>
>> The test that didn't time out but just failed has the following
>> description in
>> the log file:
>
>
> The ensuing error messages make it look like the documentation didn't build.
> Is that true?

I'm not sure -- when I run the Sage IPython, I can get documentation,
so it would appear that the documentation was built.

Cheers,
Henry

[Julien Puydt]

Le dimanche 06 mai, Henry de Valence a écrit:

> But Sage is on a microSD card instead
> of on the internal SSD, because with an 8GB SSD, there's not a lot of
> room for multiple Sage installs + all the system stuff.

Do you have any idea of how much overlap there is between all those
sage installations?

Snark on #sagemath

[Jeroen Demeyer]

On 2012-05-06 19:53, Henry de Valence wrote:
> I'm not sure -- when I run the Sage IPython, I can get documentation,
> so it would appear that the documentation was built.

Could you attach the file $SAGE_ROOT/dochtml.log
That way, we can check.

[Henry de Valence]

Hi, I've put the relevant log files here:

https://www.dropbox.com/sh/1ma1bgd3jn521jm/QLxX7G-Sgb

It looks like the documentation did fail to build:


writing output... [ 37%] sage/combinat/words/infinite_word

Exception occurred:
File "/home/hdevalence/code/sage-5.0.rc0/local/lib/python/subprocess.py",
line 1130, in _execute_child
self.pid = os.fork()
OSError: [Errno 12] Cannot allocate memory
The full traceback has been saved in /tmp/sphinx-err-GAIaQW.log, if
you want to report the issue to the developers.

So maybe this is just an issue with my machine? But it has around 3GB
of memory + swap, so it seems a bit strange that it would run out of
memory.

Is there a way to redo just this part so I can watch what happens?

Cheers,
Henry de Valence.

[Jeroen Demeyer]

On 2012-05-07 04:45, Henry de Valence wrote:
> So maybe this is just an issue with my machine? But it has around 3GB
> of memory + swap, so it seems a bit strange that it would run out of
> memory.

Sage needs about 2.5GB of memory to build the documentation, so it's not
that strange.

> Is there a way to redo just this part so I can watch what happens?

Just type "make doc" from Sage's root directory.

[Nicu Tofan]

If you look at second message in this thread you will see that I've reported a somehow similar behavior. However, there was no exception on my machine (maybe because is 64 bit and the swap space was not exhausted, yet).

Nick

[P Purkayastha]

Strangely, I am getting this error in building Sage on a freshly installed ubuntu-12.04 64bits.

libtool: compile: gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1 -DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_DENORMS=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 -DHAVE___GMPN_ROOTREM=1 -I. -I/home/punarbasu/Installations/sage-5.0.rc0/local/include -g -O3 -march=native -O3 -pipe -MT set_f.lo -MD -MP -MF .deps/set_f.Tpo -c set_f.c -fPIC -DPIC -o .libs/set_f.o
set_f.c: In function 'mpfr_set_f':
set_f.c:27:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccebl8Sx.out file, please attach this to your bugreport.
make[4]: *** [set_f.lo] Error 1
make[4]: Leaving directory `/home/punarbasu/Installations/sage-5.0.rc0/spkg/build/mpfr-3.1.0.p1/src/src'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/punarbasu/Installations/sage-5.0.rc0/spkg/build/mpfr-3.1.0.p1/src/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/punarbasu/Installations/sage-5.0.rc0/spkg/build/mpfr-3.1.0.p1/src'
Error building MPFR.

This is with gcc:

...lations/sage-5.0.rc0 [2] » gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --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.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

cpuinfo:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz
stepping        : 6
microcode       : 0x44
cpu MHz         : 1596.000
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
bogomips        : 4266.83
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

And ram:

~/Installations/sage-5.0.rc0» free -m
             total       used       free     shared    buffers     cached
Mem:          3954       1457       2497          0         70        692
-/+ buffers/cache:        694       3260
Swap:         2231          0       2231

uname:

~/Installations/sage-5.0.rc0» uname -a
Linux ub2 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

And I set the following CFLAGS, CXXFLAGS (and MAKE is empty):

~/Installations/sage-5.0.rc0» export CFLAGS="-march=native -O3 -pipe"
~/Installations/sage-5.0.rc0» export CXXFLAGS="${CFLAGS}"

The build log is attached.

[Jeroen Demeyer]

On 2012-05-09 09:34, P Purkayastha wrote:
> And I set the following CFLAGS, CXXFLAGS (and MAKE is empty):
> ||

> ~/Installations/sage-5.0.rc0�exportCFLAGS="-march=native -O3 -pipe"
> ~/Installations/sage-5.0.rc0�exportCXXFLAGS="${CFLAGS}"

What if you don't use -march=native? Could you recompile mpir and mpfr
with just "-O3 -pipe" (or other variations of CFLAGS)?

[P Purkayastha]

Actually, I already tried that. It fails in the same way.

[Jeroen Demeyer]

On 2012-05-09 09:52, P Purkayastha wrote:
> Actually, I already tried that. It fails in the same way.

And without setting any CFLAGS?

[P Purkayastha]

That's what I meant. Without having set anything. Just plain "make." 

[P Purkayastha]

It seems the CFLAGS were cached somewhere (I had run in a separate
terminal too, so it wasn't in the env). Even a "make clean" couldn't get
rid of the CFLAGS settings. I removed the whole sage directory and
unpacked a fresh one. Simple "make" is running now, and has passed the
MPFR package.

[Jeroen Demeyer]

On 2012-05-09 11:45, P Purkayastha wrote:
> On 05/09/2012 03:57 PM, P Purkayastha wrote:
>>
>>
>> On Wed, May 9, 2012 at 3:56 PM, Jeroen Demeyer <jdem...@cage.ugent.be
>> <mailto:jdem...@cage.ugent.be>> wrote:
>>
>> On 2012-05-09 09:52, P Purkayastha wrote:
>> > Actually, I already tried that. It fails in the same way.
>> And without setting any CFLAGS
>>
>>
>> That's what I meant. Without having set anything. Just plain "make."
>
> It seems the CFLAGS were cached somewhere

by MPIR. That's why I asked to recompile both MPIR and MPFR.

[P Purkayastha]

Sorry, I failed to read that.

Now, I have a new error in givaro. This looks like a problem in its
source :-/

The build log is attached.

g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -DGMP_NO_CXX
-I../../../src/kernel/memory -I../../../src/kernel/system
-I/home/punarbasu/Installations/sage-5.0.rc0/local//include -fPIC
-I/home/punarbasu/Installations/sage-5.0.rc0/local/include -MT
gmp++_int_div.lo -MD -MP -MF .deps/gmp++_int_div.Tpo -c gmp++_int_div.C
-fPIC -DPIC -o .libs/gmp++_int_div.o
In file included from ./gmp++/gmp++_int.h:402:0,
from gmp++/gmp++.h:32,
from gmp++_int_div.C:9:
./gmp++/gmp++/gmp++_int.inl: In static member function �static Integer&
Integer::random(Integer&, long int)�:
./gmp++/gmp++/gmp++_int.inl:331:44: error: �mpz_random� was not declared
in this scope
./gmp++/gmp++/gmp++_int.inl: In static member function �static Integer&
Integer::random(Integer&, const Integer&)�:
./gmp++/gmp++/gmp++_int.inl:355:80: error: �mpz_random� was not declared
in this scope
make[5]: *** [gmp++_int_div.lo] Error 1
make[5]: Leaving directory
`/home/punarbasu/Installations/sage-5.0.rc0/spkg/build/givaro-3.2.13.rc1.p3/src/src/kernel/gmp++'
make[4]: *** [install-recursive] Error 1
make[4]: Leaving directory
`/home/punarbasu/Installations/sage-5.0.rc0/spkg/build/givaro-3.2.13.rc1.p3/src/src/kernel'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory
`/home/punarbasu/Installations/sage-5.0.rc0/spkg/build/givaro-3.2.13.rc1.p3/src/src'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory
`/home/punarbasu/Installations/sage-5.0.rc0/spkg/build/givaro-3.2.13.rc1.p3/src'
Error installing givaro

[Jeroen Demeyer]

On 2012-05-09 13:06, P Purkayastha wrote:
> The build log is attached.

The problem is actually with MPIR, can you send me the MPIR log file?

[P Purkayastha]

Hi Jeroen,

I am currently not physically near that machine (and I forgot to enable
ssh on it since it is freshly installed). I will send you the file
tomorrow (in roughly 12 hours).

[P Purkayastha]

On 05/09/2012 11:08 PM, Jeroen Demeyer wrote:

Ok. Here is the MPIR log.

[Jeroen Demeyer]

I see the problem. Originally, Sage (or you) decided to install the GCC
package within Sage. As a consequence, MPIR was built without the C++
interface. From the MPIR log:
> Building a reduced version of MPIR to bootstrap GCC.
> MPIR will later get rebuilt (with the C++ interface and static libraries
> enabled) using the new compiler.
Then MPFR failed, causing the build to abort. Then you messed with
CFLAGS (and maybe compiler versions?) and rebuilt Sage but this time
*without* installing GCC. This left the "partial" MPIR build in place.

Rebuilding MPIR should fix your problem.

[P Purkayastha]

Oh. That's nice.

Indeed, the build had failed once with it trying to install gcc. While
compiling or installing gcc it complained that some headers were missing.

It turned out that the reason why it was trying to install gcc was
because I didn't have gfortran in my system. So, I installed gfortran
and restarted the build of Sage.

I already started another build of Sage to check if it works this time
round. Hopefully it should turn out fine this time.

[Dima Pasechnik]

On Thursday, 10 May 2012 07:42:44 UTC, P Purkayastha wrote:

On 05/10/2012 03:37 PM, Jeroen Demeyer wrote:
> I see the problem.  Originally, Sage (or you) decided to install the GCC
> package within Sage.  As a consequence, MPIR was built without the C++
> interface.  From the MPIR log:
>> Building a reduced version of MPIR to bootstrap GCC.
>> MPIR will later get rebuilt (with the C++ interface and static libraries
>> enabled) using the new compiler.
> Then MPFR failed, causing the build to abort.  Then you messed with
> CFLAGS (and maybe compiler versions?) and rebuilt Sage but this time
> *without* installing GCC.  This left the "partial" MPIR build in place.
>
> Rebuilding MPIR should fix your problem.
>

Oh. That's nice.

Indeed, the build had failed once with it trying to install gcc. While
compiling or installing gcc it complained that some headers were missing.

It turned out that the reason why it was trying to install gcc was
because I didn't have gfortran in my system. So, I installed gfortran
and restarted the build of Sage. 

it seems to me that missing gfortran alone should not trigger a build of the gcc spkg.

It might cause similar problems on systems which have good enough gcc to build Sage,

but which are not tested in such a scenario.

[Jeroen Demeyer]

On 2012-05-10 12:56, Dima Pasechnik wrote:
> it seems to me that missing gfortran alone should not trigger a build of
> the gcc spkg.

Several packages need a Fortran compiler. So, if gfortran is missing we
*must* build GCC.

[Dima Pasechnik]

On Thursday, 10 May 2012 11:50:39 UTC, Jeroen Demeyer wrote:

On 2012-05-10 12:56, Dima Pasechnik wrote:
> it seems to me that missing gfortran alone should not trigger a build of
> the gcc spkg.
Several packages need a Fortran compiler.  

sure, I am perfectly aware of this...

 

So, if gfortran is missing we
*must* build GCC.

This is a huge overkill, at least on Linux, where gfortran is just one call to package manager away.

 

[Jeroen Demeyer]

On 2012-05-10 14:03, Dima Pasechnik wrote:
> This is a huge overkill, at least on Linux, where gfortran is just one
> call to package manager away

If the user has root access, then yes.

[P Purkayastha]

Yes. I only needed to install gfortran system-wide to stop gcc from
building. However, I did see gcc fail to build when it was trying to
build gcc-4.6.3, the same version as the system one. And because it
failed to build gcc, I noticed that I needed gfortran; otherwise it
would have spent another hour building gcc.

[Dima Pasechnik]

IMHO  the top-level README.txt should be updated to reflect this. Currently (after #12898) it just says that Sage "automatically determines..." whether to build the gcc spkg, or not, without spelling out more details; at least it ought to mention that it will happen is gfortran is not installed.

 

[Julien Puydt]

Le jeudi 10 mai, Jeroen Demeyer a écrit:

1) There's no need for root access to install a compiler in one's
homedir.

2) I understand the convenience of being able to install sage
with minimum requirements in restricted cases, but still don't get why
such a nice endeavour means all other cases must endure a long
compilation and big installations -- why aren't all parts of sage like
gcc, and compiled *only when needed* !?

Snark on #sagemath

[P Purkayastha]

On Friday, May 11, 2012 1:19:04 AM UTC+8, Snark wrote:

2) I understand the convenience of being able to install sage
with minimum requirements in restricted cases, but still don't get why
such a nice endeavour means all other cases must endure a long
compilation and big installations -- why aren't all parts of sage like
gcc, and compiled *only when needed* !?

 

I think the problem is versioning. You will need to ensure that the correct versions are installed system wide. Supporting something like this will require a major overhaul of the build system IMHO. The current process ensures that you have a working Sage by simply typing "make". Yes, the compile times are huge and there are a lot of duplication of libraries but this is as close to a painless compiled install as you can get.

[Julien Puydt]

Le Thu, 10 May 2012 22:37:15 -0700 (PDT),
P Purkayastha <ppu...@gmail.com> a écrit :

Let me state again that I'm not against having a "just type 'make'"
sage available ; as I think was made pretty clear from the point (2)
quoted above.

Most spkg should check if their software isn't already available (with
a suitable version), and if so, just stop there.

The current situation is :
(1) most spkg install themselves unconditionally (long compilation,
huge disk use) ;
(2) worse, other pieces of sage have checks in place to break if one of
their deps wasn't installed like in step (1)!

How do other open source projects do? They have some kind of configure
check for their deps. No deps, no build. The developpers work from the
deps onward. The packagers package ; and if something is annoying for
packagers, upstream moves to make it easy. Making something available
in a "just type 'make'" fashion is just a packaging means among others.

Many projects have packages available for quite a few distributions
(linux, *BSD, windows, mac, etc), precisely because even if the
developpers don't package, the code is flexible enough to accommodate.
Packaging isn't forking. No ugly all-in-one
will-never-enter-the-main-distribution packages.

Any time I mention that, people answer :
(1) about versioning problems : it's less a problem for other projects,
since they just deal with their direct deps and don't have to care
about the deps of their deps and the deps of the deps of their deps,
etc. The recent problems with readline? If sage had used what was
there, there wouldn't be any. I provided patches for debian multiarch
support, because that will be a problem in the future : debian provides
patched programs which deal with it, but since sage doesn't go through
them...
(2) about compatibility issues : like (1).
(3) about subtle bugs : they exist, whether you take care of all
your deps yourself or just let someone else provide them. But a piece of
code used in more various situations will make them uncovered sooner and
pinpoint them better.
(4) "It's impossible!" : it is possible because many distributions exist
which have thousands of packages, and it's possible because many other
projects exist.
(5) "It's too hard!" : it's in fact simpler, since you're separating
roles more clearly (developpers vs packagers). The current sage has to
deal with problems in windows, in MOSX, in debian, in mandriva, in
sunOS, in *BSD, etc! If there's a compiler problem on one platform, let
the packagers for that platform deal with it, if it's not a code issue!
(6) "But sage is so different, so much more complex!" : oh, yes, sage is
different, but precisely because it makes every effort to do so! Oh,
yes, it is complex, but precisely because it wants to take care of the
whole tree of deps instead of only the leafs!

Notice that I'm not just ranting : I open bug reports and provide
patches (which sometimes get rejected because what every other project
would consider a bug is a sage feature!).

Snark on #sagemath