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]

[Keshav Kini]

New MPIR fails to compile on my system, which is a bit bizarre since I have the most boring architecture imaginable... x86_64 (via Virtualbox), Linux 3.2.9 (with some patches I admit), system GCC version 4.6.2...

Last few lines of the log:

Making all in mpn
make[4]: Entering directory `/opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/mpn'
/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo dummy1 | sed 's/_$//'`    -O2 -m64 -march=corei7-avx -mtune=corei7-avx  -c -o dummy1.lo dummy1.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dummy1 -O2 -m64 -march=corei7-avx -mtune=corei7-avx -c dummy1.c  -fPIC -DPIC -o .libs/dummy1.o
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dummy1 -O2 -m64 -march=corei7-avx -mtune=corei7-avx -c dummy1.c -o dummy1.o >/dev/null 2>&1
/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add | sed 's/_$//'`    -O2 -m64 -march=corei7-avx -mtune=corei7-avx  -c -o add.lo add.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add -O2 -m64 -march=corei7-avx -mtune=corei7-avx -c add.c  -fPIC -DPIC -o .libs/add.o
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add -O2 -m64 -march=corei7-avx -mtune=corei7-avx -c add.c -o add.o >/dev/null 2>&1
/bin/sh ../libtool --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo add_1 | sed 's/_$//'`    -O2 -m64 -march=corei7-avx -mtune=corei7-avx  -c -o add_1.lo add_1.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_1 -O2 -m64 -march=corei7-avx -mtune=corei7-avx -c add_1.c  -fPIC -DPIC -o .libs/add_1.o
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_1 -O2 -m64 -march=corei7-avx -mtune=corei7-avx -c add_1.c -o add_1.o >/dev/null 2>&1
/bin/sh ../libtool --mode=compile --tag=CC ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64  -o add_n.lo `test -f 'add_n.as' || echo './'`add_n.as
libtool: compile:  ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as  -fPIC -DPIC -o .libs/add_n.o
../yasm/yasm -I .. -f elf64 add_n.as -D PIC -o .libs/add_n.o
../libtool: line 1133: 24751 Illegal instruction     ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o
make[4]: *** [add_n.lo] Error 1
make[4]: Leaving directory `/opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/mpn'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src'
Error building MPIR.

Full install.log (from `SAGE_PARALLEL_SPKG_BUILD="no" MAKE="" make`) is attached, compressed with xz to save you mailbox space. Any ideas?

-Keshav

----
Join us in #sagemath on irc.freenode.net !

[Jeroen Demeyer]

On 2012-05-02 13:28, Keshav Kini wrote:
> New MPIR fails to compile on my system, which is a bit bizarre since I
> have the most boring architecture imaginable... x86_64

What's your exact CPU type?

[Keshav Kini]

On Wed, May 2, 2012 at 7:33 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> What's your exact CPU type?

Intel Core i5-2500K, architecture "Sandy Bridge" (known to GCC as
"corei7-avx"). However, this is accessed from inside a virtual machine
using VT-x extensions and so lacks many of the true features of a
corei7-avx CPU. However, GCC on my system is smart enough not to
stumble over this fact, as I have noticed before when compiling other
things than Sage. The contents of /proc/cpuinfo are as follows (I
provide only the info of the first of four cores as the information is
similar for the other three cores):

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
stepping : 7
cpu MHz : 3302.482
cache size : 6144 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc
rep_good nopl pni ssse3 lahf_lm
bogomips : 6604.96
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

[Bill Hart]

The -march=corei7-avx -mtune=corei7-avx looks suspicious.

The other thing to check is that yasm is building 64 bit assembly
files. It does look like you are using -m64 to compile the C code at
least, which is correct.

Bill.

> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/sage-release/-/qFKrbB5fQXUJ.
>
> 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.

[Bill Hart]

On 2 May 2012 12:40, Keshav Kini <kesha...@gmail.com> wrote:
> On Wed, May 2, 2012 at 7:33 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> What's your exact CPU type?
>
> Intel Core i5-2500K, architecture "Sandy Bridge" (known to GCC as
> "corei7-avx"). However, this is accessed from inside a virtual machine
> using VT-x extensions and so lacks many of the true features of a
> corei7-avx CPU. However, GCC on my system is smart enough not to
> stumble over this fact, as I have noticed before when compiling other
> things than Sage.

Yes, but the problem is not reported by GCC but by Yasm, the assembler
used to build the optimised assembly routines for MPIR.

What does ./config.guess report in the mpir build directory?

It is possible that Yasm doesn't fully support your processor
extensions or something, or that there is a bug in Yasm.

Bill.

[Keshav Kini]

On Wed, May 2, 2012 at 7:46 PM, Bill Hart <goodwi...@googlemail.com> wrote:
> Yes, but the problem is not reported by GCC but by Yasm, the assembler
> used to build the optimised assembly routines for MPIR.

Oh, good point.

> What does ./config.guess report in the mpir build directory?

fs@boone /opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src $ ./config.guess
sandybridge-unknown-linux-gnu

[Jeroen Demeyer]

Try the following:

$ cd spkg/build/mpir-2.4.0.p3/src/mpn
$ gdb ../yasm/yasm
(gdb) run -I .. -f elf64 add_n.as -D PIC -o .libs/add_n.o
... see what happens ...

[Jeroen Demeyer]

On 2012-05-02 13:40, Keshav Kini wrote:
> However, GCC on my system is smart enough not to
> stumble over this fact, as I have noticed before when compiling other
> things than Sage.

Did you compile those "other things" with some -march= or -mpcu= flag
(e.g. -march=native)?

[Keshav Kini]

My default CFLAGS include "-mtune=generic" but no -march or -mcpu
(which is what I guess you meant by -mpcu). For a time I did use
"-march=native" instead, which resolved to corei7-avx according to
`gcc -Q -march=native -O2 --help=target | grep march` (thanks to
ppurka for this command), and saw no problems there either. But as
Bill says it's probably something to do with yasm, which I guess most
packages I compiled don't have issues with.

I did manage to install my distro (Funtoo, a Gentoo variant)'s
slightly patched MPIR through the system package manager. Perhaps the
following is relevant, though I have no idea what it means:

https://github.com/funtoo/portage-mini-2011/blob/funtoo.org/sci-libs/mpir/mpir-2.4.0.ebuild#L27

The yasm patch referenced in the above file is here:
https://github.com/funtoo/portage-mini-2011/blob/funtoo.org/sci-libs/mpir/files/mpir-2.2.0-yasm.patch

[Keshav Kini]

fs@boone /opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/mpn $ gdb
../yasm/yasm
GNU gdb (Gentoo 7.4.1 p1) 7.4.1
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from
/opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/yasm/yasm...(no
debugging symbols found)...done.

(gdb) run -I .. -f elf64 add_n.as -D PIC -o .libs/add_n.o

Starting program:
/opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/yasm/yasm -I .. -f

elf64 add_n.as -D PIC -o .libs/add_n.o

Program received signal SIGILL, Illegal instruction.
0x0000000000405062 in BitVector_Boot ()
(gdb)

[Bruce]

I had a clean make on a MacOS 10.7.3 box and ran testall. All passed
except

<quote>
The following tests failed:

sage -t -force_lib "devel/sage/sage/tests/cmdline.py"
Total time for all tests: 6900.7 seconds
Please see /Users/bic/.sage//tmp/test.log for the complete log from
this test.
[rinehart:~/src/sage/sage-5.0.rc0] 11% ./sage --version
Sage Version 5.0.rc0, Release Date: 2012-05-01
</quote>


-Bruce

On May 2, 12:03 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> Dear Sage lovers,

[Jeroen Demeyer]

On 2012-05-02 16:46, Keshav Kini wrote:
> https://github.com/funtoo/portage-mini-2011/blob/funtoo.org/sci-libs/mpir/mpir-2.4.0.ebuild#L27
I doubt that's relevant.

How did Funtoo install MPIR, which CFLAGS did it use? In other words:
do you have a build log for Funtoo's build of MPIR?

[Jeroen Demeyer]

Can you send me the executable
/opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/yasm/yasm

[Keshav Kini]

On Wed, May 2, 2012 at 11:16 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Can you send me the executable
> /opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/yasm/yasm

It is now at http://boxen.math.washington.edu/home/keshav/files/yasm .

[Keshav Kini]

On Wed, May 2, 2012 at 11:08 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> How did Funtoo install MPIR, which CFLAGS did it use?  In other words:
> do you have a build log for Funtoo's build of MPIR?

I didn't save a build log, but Funtoo recorded the CFLAGS used:

fs@boone ~ $ cat /var/db/pkg/sci-libs/mpir-2.4.0/CFLAGS
-mtune=generic -O2 -pipe

I'll rerun the build after setting the package manager up to save
build logs of successfully built packages.

[Jeroen Demeyer]

On 2012-05-02 17:22, Keshav Kini wrote:
> On Wed, May 2, 2012 at 11:08 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> How did Funtoo install MPIR, which CFLAGS did it use? In other words:
>> do you have a build log for Funtoo's build of MPIR?
>
> I didn't save a build log, but Funtoo recorded the CFLAGS used:
>
> fs@boone ~ $ cat /var/db/pkg/sci-libs/mpir-2.4.0/CFLAGS
> -mtune=generic -O2 -pipe

That's enough information. The problem is with -mcpu=corei7-avx

[John Cremona]

Built fine and all long tests pass on:

Linux fermat 2.6.32-37-server #81-Ubuntu SMP Fri Dec 2 20:49:12 UTC
2011 x86_64 GNU/Linux
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)

John

> --
> You received this message because you are subscribed to the Google Groups "sage-release" group.

[Jeroen Demeyer]

On 2012-05-02 13:28, Keshav Kini wrote:

> New MPIR fails to compile on my system, which is a bit bizarre since I
> have the most boring architecture imaginable... x86_64 (via Virtualbox),
> Linux 3.2.9 (with some patches I admit), system GCC version 4.6.2...

This might be a bug in VirtualBox:
https://www.virtualbox.org/ticket/8651

I don't know enough about virtualization to understand how the guest CPU
might support less instructions than the host CPU though...

[Keshav Kini]

I ran the Funtoo build again with CFLAGS="-mcpu=corei7-avx -O2 -pipe",
still no problems. The build log is here, if you want to see it:
http://boxen.math.washington.edu/home/keshav/files/sci-libs:mpir-2.4.0:20120502-153037.log

[Jeroen Demeyer]

On 2012-05-02 17:35, Keshav Kini wrote:
> On Wed, May 2, 2012 at 11:25 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> On 2012-05-02 17:22, Keshav Kini wrote:
>>> On Wed, May 2, 2012 at 11:08 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>>>> How did Funtoo install MPIR, which CFLAGS did it use? In other words:
>>>> do you have a build log for Funtoo's build of MPIR?
>>>
>>> I didn't save a build log, but Funtoo recorded the CFLAGS used:
>>>
>>> fs@boone ~ $ cat /var/db/pkg/sci-libs/mpir-2.4.0/CFLAGS
>>> -mtune=generic -O2 -pipe
>>
>> That's enough information. The problem is with -mcpu=corei7-avx
>
> I ran the Funtoo build again with CFLAGS="-mcpu=corei7-avx -O2 -pipe",

Sorry, that should be -march, not -mcpu

[Keshav Kini]

On Wed, May 2, 2012 at 11:41 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> I ran the Funtoo build again with CFLAGS="-mcpu=corei7-avx -O2 -pipe",
>
> Sorry, that should be -march, not -mcpu

I ran the Funtoo build again with CFLAGS="-march=corei7-avx -O2

-pipe", still no problems. The build log is here, if you want to see

it: http://boxen.math.washington.edu/home/keshav/files/sci-libs:mpir-2.4.0:20120502-154146.log
:)

[Volker Braun]

On Wednesday, May 2, 2012 11:32:33 AM UTC-4, Jeroen Demeyer wrote:

I don't know enough about virtualization to understand how the guest CPU
might support less instructions than the host CPU though...

The VM dynamically translates the binary into one where dangerous instructions are replaced by VM code. So any instructions that the VM doesn't know about aren't available to the guest.

[Jeroen Demeyer]

Okay, I'm not finished yet. In Gentoo (so I can only assume also in
Funtoo), yasm is actually a *separate* ebuild from mpir. So you need to
recompile both yasm and mpir with -march=corei7-avx

[Jeroen Demeyer]

Okay, upgrading VirtualBox might solve the problem then.

[Keshav Kini]

On Wed, May 2, 2012 at 11:51 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> Okay, upgrading VirtualBox might solve the problem then.

I'm running the latest VirtualBox release, 4.1.14. The feature request
you linked has not been closed yet...

[Keshav Kini]

Bam! yasm rebuilt with -march=corei7-avx just fine, but then mpir
failed in the same way that Sage's mpir spkg failed. :)

[Volker Braun]

Also, I thought you said MPIR uses autoconf-style test to check that SSE4 is supported. But it seems more like it just looks at /proc/cpuinfo and happily builds yasm with non-supported instructions.

[Keshav Kini]

On Wed, May 2, 2012 at 11:56 PM, Keshav Kini <kesha...@gmail.com> wrote:
> Bam! yasm rebuilt with -march=corei7-avx just fine, but then mpir
> failed in the same way that Sage's mpir spkg failed. :)

But rebuilding yasm and mpir with -march=native works just fine...
even though `gcc -Q -march=native -O2 --help=target | grep march`
returns "-march=corei7-avx".

[Jeroen Demeyer]

On 2012-05-02 17:56, Keshav Kini wrote:
> On Wed, May 2, 2012 at 11:51 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>> Okay, I'm not finished yet. In Gentoo (so I can only assume also in
>> Funtoo), yasm is actually a *separate* ebuild from mpir. So you need to
>> recompile both yasm and mpir with -march=corei7-avx
>
> Bam! yasm rebuilt with -march=corei7-avx just fine, but then mpir
> failed in the same way that Sage's mpir spkg failed. :)

Just for fun: can you repeat building yasm and mpir with -march=native
instead?

[Jeroen Demeyer]

What is the full output of

[Jeroen Demeyer]

On 2012-05-02 18:00, Volker Braun wrote:
> Also, I thought you said MPIR uses autoconf-style test to check that
> SSE4 is supported.

Well, it tests that SSE4 code can be compiled, not that it actually
runs. This is useful for cross-compiling or building "fat" binaries
which run on architectures not supported by the build system.

[Keshav Kini]

On Thu, May 3, 2012 at 12:06 AM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> What is the full output of
> gcc -Q -march=native -O2 --help=target

fs@boone ~ $ gcc -Q -march=native -O2 --help=target
The following options are target specific:
-m128bit-long-double [disabled]
-m32 [disabled]
-m3dnow [disabled]
-m3dnowa [disabled]
-m64 [enabled]
-m80387 [enabled]
-m8bit-idiv [disabled]
-m96bit-long-double [enabled]
-mabi=
-mabm [disabled]
-maccumulate-outgoing-args [disabled]
-maes [disabled]
-malign-double [disabled]
-malign-functions=
-malign-jumps=
-malign-loops=
-malign-stringops [enabled]
-mandroid [disabled]
-march= corei7-avx
-masm=
-mavx [disabled]
-mavx256-split-unaligned-load [disabled]
-mavx256-split-unaligned-store [disabled]
-mbionic [disabled]
-mbmi [disabled]
-mbranch-cost=
-mcld [disabled]
-mcmodel=
-mcpu=
-mcrc32 [disabled]
-mcx16 [disabled]
-mdispatch-scheduler [disabled]
-mf16c [disabled]
-mfancy-math-387 [enabled]
-mfentry [enabled]
-mfma [disabled]
-mfma4 [disabled]
-mforce-drap [disabled]
-mfp-ret-in-387 [enabled]
-mfpmath=
-mfsgsbase [disabled]
-mfused-madd
-mglibc [enabled]
-mhard-float [enabled]
-mieee-fp [enabled]
-mincoming-stack-boundary=
-minline-all-stringops [disabled]
-minline-stringops-dynamically [disabled]
-mintel-syntax
-mlarge-data-threshold=
-mlwp [disabled]
-mmmx [disabled]
-mmovbe [disabled]
-mms-bitfields [disabled]
-mno-align-stringops [disabled]
-mno-fancy-math-387 [disabled]
-mno-push-args [disabled]
-mno-red-zone [disabled]
-mno-sse4 [enabled]
-momit-leaf-frame-pointer [disabled]
-mpc
-mpclmul [disabled]
-mpopcnt [disabled]
-mprefer-avx128 [disabled]
-mpreferred-stack-boundary=
-mpush-args [enabled]
-mrdrnd [disabled]
-mrecip [disabled]
-mred-zone [enabled]
-mregparm=
-mrtd [disabled]
-msahf [enabled]
-msoft-float [disabled]
-msse [disabled]
-msse2 [disabled]
-msse2avx [disabled]
-msse3 [disabled]
-msse4 [disabled]
-msse4.1 [disabled]
-msse4.2 [disabled]
-msse4a [disabled]
-msse5
-msseregparm [disabled]
-mssse3 [disabled]
-mstack-arg-probe [disabled]
-mstackrealign [enabled]
-mstringop-strategy=
-mtbm [disabled]
-mtls-dialect=
-mtls-direct-seg-refs [enabled]
-mtune= corei7-avx
-muclibc [disabled]
-mveclibabi=
-mvect8-ret-in-mem [disabled]
-mvzeroupper [disabled]
-mxop [disabled]

fs@boone ~ $

Pretty pitiful, eh? :) No SSE whatsoever!

[Jeroen Demeyer]

I guess it's a bad test. On my system (a Core2), I get similar output.

[Jeroen Demeyer]

On 2012-05-02 18:02, Keshav Kini wrote:
> On Wed, May 2, 2012 at 11:56 PM, Keshav Kini <kesha...@gmail.com> wrote:
>> Bam! yasm rebuilt with -march=corei7-avx just fine, but then mpir
>> failed in the same way that Sage's mpir spkg failed. :)
>
> But rebuilding yasm and mpir with -march=native works just fine...
> even though `gcc -Q -march=native -O2 --help=target | grep march`
> returns "-march=corei7-avx".

I have no explanation for this...
Also, the output from gcc -Q --help=target doesn't really help.

[Dima Pasechnik]

On Wednesday, May 2, 2012 4:09:40 PM UTC, Keshav Kini wrote:

just another proof that Windoze is evil ;–) 

[Keshav Kini]

On Thu, May 3, 2012 at 1:44 AM, Dima Pasechnik <dim...@gmail.com> wrote:
> just another proof that Windoze is evil ;–)

Huh? What does this have to do with Windows?

[Andrey Novoseltsev]

On our department server I now get

checking whether to enable maintainer-specific portions of
Makefiles... no
checking ABI=64
checking compiler gcc -O2 -m64 ... no, gcc-4.3.2 on 64bit is bad,
program does not run
configure: error: could not find a working compiler, see config.log
for details
Error configuring MPIR (with CFLAGS unset).

Never had any issues building Sage on it before.

Andrey

[Jeroen Demeyer]

What does spkg/build/mpir-*/src/config.log say?

[Andrey Novoseltsev]

Here it is:
http://www.math.ualberta.ca/~novoseltsev/config.log

[Bill Hart]

I'm sure you guys probably already know this, but you can't build MPIR
(or GMP) with gcc-4.3.2 on x86_64 machines. The compiler is too
broken.

Bill.

[Andrey Novoseltsev]

On May 2, 12:25 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> I'm sure you guys probably already know this, but you can't build MPIR
> (or GMP) with gcc-4.3.2 on x86_64 machines. The compiler is too
> broken.
>
> Bill.

So the only option is to have our admin to upgrade gcc? What version
does it have to be?

[Keshav Kini]

On Thu, May 3, 2012 at 2:27 AM, Andrey Novoseltsev <novo...@gmail.com> wrote:
> So the only option is to have our admin to upgrade gcc? What version
> does it have to be?

I should hope the GCC SPKG can take care of this...

[Bill Hart]

I thought Sage built its own gcc in this case? This is necessary
because some major distribution decided that it would be a good idea
to distribute a default version of the compiler that wasn't even able
to build its own dependencies on the most popular architecture.

Anyhow, in answer to your question, any recent version of gcc other
than that one should be fine. (I don't remember if MPIR builds on
gcc-4.7.0 yet. Probably not.)

Bill.

[Jeroen Demeyer]

On 2012-05-02 20:25, Bill Hart wrote:
> I'm sure you guys probably already know this, but you can't build MPIR
> (or GMP) with gcc-4.3.2 on x86_64 machines.

Not even with CFLAGS=-O0 ?

This would be sufficient to build GCC.

[R. Andrew Ohana]

FYI, MPIR compiled fine with my native Funtoo system (also sandy
bridge with gcc-4.6.2), so it is likely to be a VM thing. Has anyone
else tried compiling from within a VM (potentially with a different
distro)?

> --
> 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.
>

--
Andrew

[Kwankyu Lee]

Clean make and test on Mac Pro with 2 quad-core intel xeon processors and OS 10.7.3 Lion, except that I saw a couple of warnings that say that it included system header files <vector> and <string>.

[Dan Drake]

On Wed, 02 May 2012 at 09:03AM +0200, Jeroen Demeyer wrote:
> We're releasing Sage 5.0.rc0.

Builds fine and passes all tests on Ubuntu 10.04, x64-64, with
SAGE_CHECK=yes.

On Ubuntu 12.04 x86-64, the ppl package failed with SAGE_CHECK=yes with
the infamous mipproblem1 compilation. I installed that package without
SAGE_CHECK, installed everything else with SAGE_CHECK, and passed all
long doctests.

Dan

--
--- Dan Drake
----- http://mathsci.kaist.ac.kr/~drake
-------

[Dima Pasechnik]

On Wednesday, May 2, 2012 8:04:23 PM UTC, R. Andrew Ohana wrote:

FYI, MPIR compiled fine with my native Funtoo system (also sandy
bridge with gcc-4.6.2), so it is likely to be a VM thing. Has anyone
else tried compiling from within a VM (potentially with a different
distro)? 

rc0 built just fine on a VMWare VM Linux Debian machine we have here.

That's not Virtual Box though, the VMWare thing is surely using all the processor

capabilities:

$ uname -a

Linux spms-banana 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux

 

On Wed, May 2, 2012 at 12:00 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> On 2012-05-02 20:25, Bill Hart wrote:
>> I'm sure you guys probably already know this, but you can't build MPIR
>> (or GMP) with gcc-4.3.2 on x86_64 machines.
> Not even with CFLAGS=-O0 ?
>
> This would be sufficient to build GCC.
>
> --
> 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+unsubscribe@googlegroups.com.

[Adam Webb]

On May 2, 2:04 pm, "R. Andrew Ohana" <andrew.oh...@gmail.com> wrote:
> FYI, MPIR compiled fine with my native Funtoo system (also sandy
> bridge with gcc-4.6.2), so it is likely to be a VM thing. Has anyone
> else tried compiling from within a VM (potentially with a different
> distro)?
>

> On Wed, May 2, 2012 at 12:00 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> > On 2012-05-02 20:25, Bill Hart wrote:
> >> I'm sure you guys probably already know this, but you can't build MPIR
> >> (or GMP) with gcc-4.3.2 on x86_64 machines.
> > Not even with CFLAGS=-O0 ?
>
> > This would be sufficient to build GCC.
>
> > --
> > 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 athttp://groups.google.com/group/sage-release?hl=en.
>
> --
> Andrew

I tried to build sage and was not able to. It stopped at MPIR as
already mentioned. I am using vmware player 4.02 on Windows 7. I am
running Ubuntu 12.04 (64 bit) in the VM.

It gives somewhat different results for the gcc command given:

$ gcc -Q -march=native -O2 --help=target

I also tried export SAGE_INSTALL_GCC="yes" to force building gcc but
this failed. It tries to build a reduced mpir in order to build gcc
but the build fails.


Cheers,
Adam

[Dima Pasechnik]

On Thursday, May 3, 2012 3:10:12 AM UTC, Dima Pasechnik wrote:

On Wednesday, May 2, 2012 8:04:23 PM UTC, R. Andrew Ohana wrote:

FYI, MPIR compiled fine with my native Funtoo system (also sandy
bridge with gcc-4.6.2), so it is likely to be a VM thing. Has anyone
else tried compiling from within a VM (potentially with a different
distro)? 

rc0 built just fine on a VMWare VM Linux Debian machine we have here.

That's not Virtual Box though, the VMWare thing is surely using all the processor

capabilities:

$ uname -a

Linux spms-banana 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux

forgot to say that the hardware itself runs one of VMWare's Infrastructure (vmkernel?) software, a kind of Unix, I guess.

 

 

On Wed, May 2, 2012 at 12:00 PM, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
> On 2012-05-02 20:25, Bill Hart wrote:
>> I'm sure you guys probably already know this, but you can't build MPIR
>> (or GMP) with gcc-4.3.2 on x86_64 machines.
> Not even with CFLAGS=-O0 ?
>
> This would be sufficient to build GCC.
>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-release?hl=en.
>



--
Andrew

[Robert Bradshaw]

Now that we're shipping gcc, I decided to try it on my old PPC box
(which would be good for 32-bit, big-endian testing among other
things). There was a failure with gdmodule:

/Volumes/BigBackup/sage/sage-5.0.rc0/spkg/pipestatus "sage-spkg
${SAGE_SPKG_OPTS} gdmodule-0.56.p7 2>&1" "tee -a
/Volumes/BigBackup/sage/sage-5.0.rc0/spkg/logs/gdmodule-0.56.p7.log"
gdmodule-0.56.p7
====================================================
Extracting package
/Volumes/BigBackup/sage/sage-5.0.rc0/spkg/standard/gdmodule-0.56.p7.spkg
-rw-r--r-- 1 robert robert 44661 Jul 25 2010
/Volumes/BigBackup/sage/sage-5.0.rc0/spkg/standard/gdmodule-0.56.p7.spkg
Finished extraction
****************************************************
Host system:
Darwin ombre.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh
powerpc
****************************************************
C compiler: gcc
C compiler version:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Volumes/BigBackup/sage/sage-5.0.rc0/local/libexec/gcc/powerpc-apple-darwin8.11.0/4.6.3/lto-wrapper
Target: powerpc-apple-darwin8.11.0
Configured with: ../src/configure
--prefix=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-local-prefix=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-gmp=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-mpfr=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-mpc=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-system-zlib --disable-multilib
Thread model: posix
gcc version 4.6.3 (GCC)
...
gcc -fno-strict-aliasing -fwrapv -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -DHAVE_LIBGD -DHAVE_LIBPNG -DHAVE_LIBZ
-DHAVE_LIBFREETYPE
-I/Volumes/BigBackup/sage/sage-5.0.rc0/local/include
-I/usr/local/include -I/sw/include -I/usr/include -I/usr/include/X11
-I/usr/X11R6/include
-I/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7 -c
_gdmodule.c -o build/temp.macosx-10.4-ppc-2.7/_gdmodule.o
_gdmodule.c:152:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
_gdmodule.c:169:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
_gdmodule.c:176:18: error: 'gdFontGetTiny' undeclared here (not in a function)
...
_gdmodule.c:2177:28: error: 'gdAntiAliased' undeclared (first use in
this function)
_gdmodule.c:2177:28: note: each undeclared identifier is reported only
once for each function it appears in
error: command 'gcc' failed with exit status 1
Failure to build gdmodule

real 0m0.703s
user 0m0.267s
sys 0m0.245s
************************************************************************
Error installing package gdmodule-0.56.p7
************************************************************************


Full logs at http://sage.math.washington.edu/home/robertwb/sage-5.0.rc0-logs/

- Robert

On Wed, May 2, 2012 at 12:03 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.
>
> == 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]

>
> --
> 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.

[Justin C. Walker]

On May 2, 2012, at 00:03 , Jeroen Demeyer 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

Built from scratch on two platforms:

Mac OS X, 10.6.8 (Dual 6-core Xeons): build, doc build, test ('ptestlong'): no problems and all tests passed!

Mac OS X, 10.7.1 (4-core Core i7): build, doc build, test ('ptestlong'): no problems and all tests passed!

Yay! Great work.

One oddity: my first attempt to build on 10.7 blew up with MPIR. Unfortunately, I didn't keep the carcass around for later examination. The second attempt, with a fresh install, worked without a problem.

I am trying a few more "fresh" builds on 10.7 to see whether this repeats.

Justin

--
Justin C. Walker
Curmudgeon-at-large
Director
Institute for the Absorption of Federal Funds
----
186,000 Miles per Second
Not just a good idea:
it's the law!
----

[Keshav Kini]

On Thu, May 3, 2012 at 11:10 AM, Dima Pasechnik <dim...@gmail.com> wrote:
> rc0 built just fine on a VMWare VM Linux Debian machine we have here.
> That's not Virtual Box though, the VMWare thing is surely using all the
> processor
> capabilities:
> $ uname -a
> Linux spms-banana 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64
> GNU/Linux

Well, regardless of whether vmware is able to support more processor
features in the emulated guest CPU, note that this machine's hardware
CPU is not of the sandy bridge architecture, so possibly the "illegal
instruction" that yasm generated doesn't show up in this case. To test
whether this is really virtualbox-specific someone needs to try vmware
on a sandy bridge machine.

I gather that the "correct" way to fix this is to use --march=native
when building yasm (?).

By the way:

keshav@spms-banana ~ $ grep -E "flags|model name" /proc/cpuinfo | head
-2
model name : Intel(R) Xeon(R) CPU X5460 @ 3.16GHz
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 syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good xtopology tsc_reliable
nonstop_tsc aperfmperf pni ssse3 cx16 sse4_1 lahf_lm
fs@boone /opt/sage-5.0.rc0/spkg/build/mpir-2.4.0.p3/src/mpn $ grep -E
"flags|model name" /proc/cpuinfo | head -2
model name : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc
rep_good nopl pni ssse3 lahf_lm

So indeed there are more flags on the vmware VM running on... a Xeon,
it looks like? than on my virtualbox VM. Specifically it has dts,
acpi, ss, arch_perfmon, pebs, bts, xtopology, tsc_reliable,
nonstop_tsc, aperfmperf, pni, cx16, and sse4_1, and my virtualbox VM
doesn't. My VM has ht, which banana doesn't. I don't know how much
these differences are attributable to the differences between the
hardware architectures, of course.

-Keshav

----
Join us in #sagemath on irc.freenode.net !

>
>>
>>

>> On Wed, May 2, 2012 at 12:00 PM, Jeroen Demeyer <jdem...@cage.ugent.be>
>> wrote:
>> > On 2012-05-02 20:25, Bill Hart wrote:
>> >> I'm sure you guys probably already know this, but you can't build MPIR
>> >> (or GMP) with gcc-4.3.2 on x86_64 machines.
>> > Not even with CFLAGS=-O0 ?
>> >
>> > This would be sufficient to build GCC.
>> >
>> > --
>> > 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.
>> >
>>
>>
>>
>> --
>> Andrew
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/sage-release/-/6O8vsSutfYMJ.

>
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to

> sage-release...@googlegroups.com.

[Jeroen Demeyer]

On 2012-05-03 08:10, Robert Bradshaw wrote:
> Now that we're shipping gcc, I decided to try it on my old PPC box
> (which would be good for 32-bit, big-endian testing among other
> things). There was a failure with gdmodule:
>
> /Volumes/BigBackup/sage/sage-5.0.rc0/spkg/pipestatus "sage-spkg
> ${SAGE_SPKG_OPTS} gdmodule-0.56.p7 2>&1" "tee -a
> /Volumes/BigBackup/sage/sage-5.0.rc0/spkg/logs/gdmodule-0.56.p7.log"
> gdmodule-0.56.p7
> ====================================================
> Extracting package
> /Volumes/BigBackup/sage/sage-5.0.rc0/spkg/standard/gdmodule-0.56.p7.spkg
> -rw-r--r-- 1 robert robert 44661 Jul 25 2010
> /Volumes/BigBackup/sage/sage-5.0.rc0/spkg/standard/gdmodule-0.56.p7.spkg
> Finished extraction
> ****************************************************
> Host system:
> Darwin ombre.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10
> 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh
> powerpc

On a system which seems to be exactly the same, I did manage to build
gdmodule:

http://build.sagemath.org/sage/builders/UGent%20moufang%20%28OSX%2010.4%20ppc32%29/builds/54/steps/shell_5/logs/gdmodule

Maybe it's a different version of XCode or something else on your system
which is conflicting? I have no idea...

[Jeroen Demeyer]

Please try:

$ ./sage --sh
(sage-sh) cd spkg/build/gdmodule-0.56.p7/src
(sage-sh) gcc -save-temps -fno-strict-aliasing -fwrapv -DNDEBUG -g

-fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBGD -DHAVE_LIBPNG
-DHAVE_LIBZ -DHAVE_LIBFREETYPE
-I/Volumes/BigBackup/sage/sage-5.0.rc0/local/include
-I/usr/local/include -I/sw/include -I/usr/include -I/usr/include/X11
-I/usr/X11R6/include
-I/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7 -c
_gdmodule.c -o build/temp.macosx-10.4-ppc-2.7/_gdmodule.o

(this is the command which failed but with -save-temps added)

Then send me _gdmodule.i

[Jeroen Demeyer]

Maybe also add the -v option and send me the console output.

[Jeroen Demeyer]

On 2012-05-03 08:10, Robert Bradshaw wrote:

> Now that we're shipping gcc, I decided to try it on my old PPC box
> (which would be good for 32-bit, big-endian testing among other
> things). There was a failure with gdmodule:

Can you try also whether pil installs?

[leif]

Bill Hart wrote:
> On 2 May 2012 19:27, Andrey Novoseltsev<novo...@gmail.com> wrote:
>> On May 2, 12:25 pm, Bill Hart<goodwillh...@googlemail.com> wrote:
>>> I'm sure you guys probably already know this, but you can't build MPIR
>>> (or GMP) with gcc-4.3.2 on x86_64 machines. The compiler is too
>>> broken.
>>>
>>> Bill.
>>
>> So the only option is to have our admin to upgrade gcc? What version
>> does it have to be?
>>
>
> I thought Sage built its own gcc in this case?

It would by default. But you may run into other problems, at least on
newer CPUs, since Sage doesn't ship / update the whole toolchain (e.g.
'gas' or binutils).

> Anyhow, in answer to your question, any recent version of gcc other
> than that one should be fine. (I don't remember if MPIR builds on
> gcc-4.7.0 yet. Probably not.)

MPIR 2.4.0 and 2.5.1 build just fine with GCC 4.7.0 on a couple of
x86_64 CPUs (but Sage doesn't yet fully build with GCC 4.7); major
trouble is on ia64 (Itanium).

So GCC 4.6.3 would probably be a better choice, also updating binutils.


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[leif]

leif wrote:
> Bill Hart wrote:
>> On 2 May 2012 19:27, Andrey Novoseltsev<novo...@gmail.com> wrote:
>>> On May 2, 12:25 pm, Bill Hart<goodwillh...@googlemail.com> wrote:
>>>> I'm sure you guys probably already know this, but you can't build MPIR
>>>> (or GMP) with gcc-4.3.2 on x86_64 machines. The compiler is too
>>>> broken.
>>>>
>>>> Bill.
>>>
>>> So the only option is to have our admin to upgrade gcc? What version
>>> does it have to be?
>>>
>>
>> I thought Sage built its own gcc in this case?
>
> It would by default. But you may run into other problems, at least on
> newer CPUs, since Sage doesn't ship / update the whole toolchain (e.g.
> 'gas' or binutils).

And of course, as you mentioned, GCC 4.3.2 is not even able to build its
own prerequisites, so Sage isn't able to bootstrap the GCC spkg either
(since it first builds MPIR and MPFR with the system's compiler).

[leif]

Bill Hart wrote:
> On 2 May 2012 12:40, Keshav Kini<kesha...@gmail.com> wrote:
>> On Wed, May 2, 2012 at 7:33 PM, Jeroen Demeyer<jdem...@cage.ugent.be> wrote:
>>> What's your exact CPU type?
>>
>> Intel Core i5-2500K, architecture "Sandy Bridge" (known to GCC as
>> "corei7-avx"). However, this is accessed from inside a virtual machine
>> using VT-x extensions and so lacks many of the true features of a
>> corei7-avx CPU. However, GCC on my system is smart enough not to
>> stumble over this fact, as I have noticed before when compiling other
>> things than Sage.
>
> Yes, but the problem is not reported by GCC but by Yasm, the assembler
> used to build the optimised assembly routines for MPIR.

It isn't reported /by/ yasm, but /for/ yasm by the shell executing
libtool, which gets a SIGILL for one of its children.


-leif

> What does ./config.guess report in the mpir build directory?
>
> It is possible that Yasm doesn't fully support your processor
> extensions or something, or that there is a bug in Yasm.
>
> Bill.

[leif]

Keshav Kini wrote:
> On Wed, May 2, 2012 at 10:36 PM, Jeroen Demeyer<jdem...@cage.ugent.be> wrote:

>> On 2012-05-02 13:40, Keshav Kini wrote:
>>> However, GCC on my system is smart enough not to
>>> stumble over this fact, as I have noticed before when compiling other
>>> things than Sage.

>> Did you compile those "other things" with some -march= or -mpcu= flag
>> (e.g. -march=native)?
>
> My default CFLAGS include "-mtune=generic" but no -march or -mcpu
> (which is what I guess you meant by -mpcu). For a time I did use
> "-march=native" instead, which resolved to corei7-avx according to
> `gcc -Q -march=native -O2 --help=target | grep march` (thanks to
> ppurka for this command), and saw no problems there either. But as
> Bill says it's probably something to do with yasm, which I guess most
> packages I compiled don't have issues with.
>
> I did manage to install my distro (Funtoo, a Gentoo variant)'s
> slightly patched MPIR through the system package manager. Perhaps the
> following is relevant, though I have no idea what it means:
>
> https://github.com/funtoo/portage-mini-2011/blob/funtoo.org/sci-libs/mpir/mpir-2.4.0.ebuild#L27
>
> The yasm patch referenced in the above file is here:
> https://github.com/funtoo/portage-mini-2011/blob/funtoo.org/sci-libs/mpir/files/mpir-2.2.0-yasm.patch

That just prevents MPIR from building and using its own yasm, since
Gentoo/Funtoo have their own yasm packages (as you later noticed ;-) ).


-leif

[Bill Hart]

On 3 May 2012 15:13, leif <not.r...@online.de> wrote:
> Bill Hart wrote:
>>
>> On 2 May 2012 12:40, Keshav Kini<kesha...@gmail.com>  wrote:
>>>
>>> On Wed, May 2, 2012 at 7:33 PM, Jeroen Demeyer<jdem...@cage.ugent.be>
>>>  wrote:
>>>>
>>>> What's your exact CPU type?
>>>
>>>
>>> Intel Core i5-2500K, architecture "Sandy Bridge" (known to GCC as
>>> "corei7-avx"). However, this is accessed from inside a virtual machine
>>> using VT-x extensions and so lacks many of the true features of a
>>> corei7-avx CPU. However, GCC on my system is smart enough not to
>>> stumble over this fact, as I have noticed before when compiling other
>>> things than Sage.
>>
>>
>> Yes, but the problem is not reported by GCC but by Yasm, the assembler
>> used to build the optimised assembly routines for MPIR.
>
>
> It isn't reported /by/ yasm, but /for/ yasm by the shell executing libtool,
> which gets a SIGILL for one of its children.
>

Ah, thanks, my mistake!

Bill

[Robert Bradshaw]

(sage-sh) robert@ombre:src$ gcc -save-temps -v -fno-strict-aliasing

-fwrapv -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_LIBGD
-DHAVE_LIBPNG -DHAVE_LIBZ -DHAVE_LIBFREETYPE
-I/Volumes/BigBackup/sage/sage-5.0.rc0/local/include
-I/usr/local/include -I/sw/include -I/usr/include -I/usr/include/X11
-I/usr/X11R6/include
-I/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7 -c
_gdmodule.c -o build/temp.macosx-10.4-ppc-2.7/_gdmodule.o

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Volumes/BigBackup/sage/sage-5.0.rc0/local/libexec/gcc/powerpc-apple-darwin8.11.0/4.6.3/lto-wrapper
Target: powerpc-apple-darwin8.11.0
Configured with: ../src/configure
--prefix=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-local-prefix=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-gmp=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-mpfr=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-mpc=/Volumes/BigBackup/sage/sage-5.0.rc0/local
--with-system-zlib --disable-multilib
Thread model: posix
gcc version 4.6.3 (GCC)

COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-save-temps' '-v'
'-fno-strict-aliasing' '-D' 'NDEBUG' '-g' '-fwrapv' '-O3' '-Wall'
'-Wstrict-prototypes' '-D' 'HAVE_LIBGD' '-D' 'HAVE_LIBPNG' '-D'
'HAVE_LIBZ' '-D' 'HAVE_LIBFREETYPE' '-I'
'/Volumes/BigBackup/sage/sage-5.0.rc0/local/include' '-I'
'/usr/local/include' '-I' '/sw/include' '-I' '/usr/include' '-I'
'/usr/include/X11' '-I' '/usr/X11R6/include' '-I'
'/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7' '-c'
'-o' 'build/temp.macosx-10.4-ppc-2.7/_gdmodule.o'
/Volumes/BigBackup/sage/sage-5.0.rc0/local/libexec/gcc/powerpc-apple-darwin8.11.0/4.6.3/cc1
-E -quiet -v -I /Volumes/BigBackup/sage/sage-5.0.rc0/local/include -I
/usr/local/include -I /sw/include -I /usr/include -I /usr/include/X11
-I /usr/X11R6/include -I
/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7
-D__DYNAMIC__ -D NDEBUG -D HAVE_LIBGD -D HAVE_LIBPNG -D HAVE_LIBZ -D
HAVE_LIBFREETYPE _gdmodule.c -feliminate-unused-debug-symbols -fPIC
-mmacosx-version-min=10.4 -Wall -Wstrict-prototypes
-fno-strict-aliasing -fwrapv -g -fworking-directory -O3
-fpch-preprocess -o _gdmodule.i
ignoring nonexistent directory
"/Volumes/BigBackup/sage/sage-5.0.rc0/local/lib/gcc/powerpc-apple-darwin8.11.0/4.6.3/../../../../powerpc-apple-darwin8.11.0/include"
ignoring duplicate directory
"/Volumes/BigBackup/sage/sage-5.0.rc0/local/include"
as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "/usr/include"
as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/sw/include
/usr/include/X11
/usr/X11R6/include
/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7
/Volumes/BigBackup/sage/sage-5.0.rc0/local/lib/gcc/powerpc-apple-darwin8.11.0/4.6.3/include
/Volumes/BigBackup/sage/sage-5.0.rc0/local/include
/Volumes/BigBackup/sage/sage-5.0.rc0/local/lib/gcc/powerpc-apple-darwin8.11.0/4.6.3/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.4' '-save-temps' '-v'
'-fno-strict-aliasing' '-D' 'NDEBUG' '-g' '-fwrapv' '-O3' '-Wall'
'-Wstrict-prototypes' '-D' 'HAVE_LIBGD' '-D' 'HAVE_LIBPNG' '-D'
'HAVE_LIBZ' '-D' 'HAVE_LIBFREETYPE' '-I'
'/Volumes/BigBackup/sage/sage-5.0.rc0/local/include' '-I'
'/usr/local/include' '-I' '/sw/include' '-I' '/usr/include' '-I'
'/usr/include/X11' '-I' '/usr/X11R6/include' '-I'
'/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7' '-c'
'-o' 'build/temp.macosx-10.4-ppc-2.7/_gdmodule.o'
/Volumes/BigBackup/sage/sage-5.0.rc0/local/libexec/gcc/powerpc-apple-darwin8.11.0/4.6.3/cc1
-fpreprocessed _gdmodule.i -feliminate-unused-debug-symbols -fPIC
-quiet -dumpbase _gdmodule.c -mmacosx-version-min=10.4 -auxbase-strip
build/temp.macosx-10.4-ppc-2.7/_gdmodule.o -g -O3 -Wall
-Wstrict-prototypes -version -fno-strict-aliasing -fwrapv -o
_gdmodule.s
GNU C (GCC) version 4.6.3 (powerpc-apple-darwin8.11.0)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version
3.1.0-p8, MPC version 1.0.0dev
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.3 (powerpc-apple-darwin8.11.0)
compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version
3.1.0-p8, MPC version 1.0.0dev
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7d5be7e54ce9bdfcdd8df9b696db2967

_gdmodule.c:152:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
_gdmodule.c:169:1: warning: function declaration isn't a prototype
[-Wstrict-prototypes]
_gdmodule.c:176:18: error: 'gdFontGetTiny' undeclared here (not in a function)

_gdmodule.c:177:19: error: 'gdFontGetSmall' undeclared here (not in a function)
_gdmodule.c:178:24: error: 'gdFontGetMediumBold' undeclared here (not
in a function)
_gdmodule.c:179:19: error: 'gdFontGetLarge' undeclared here (not in a function)
_gdmodule.c:180:19: error: 'gdFontGetGiant' undeclared here (not in a function)
_gdmodule.c: In function 'image_setantialiased':
_gdmodule.c:658:5: warning: implicit declaration of function
'gdImageSetAntiAliased' [-Wimplicit-function-declaration]
_gdmodule.c: In function 'image_setclip':
_gdmodule.c:688:5: warning: implicit declaration of function
'gdImageSetClip' [-Wimplicit-function-declaration]
_gdmodule.c: In function 'image_string':
_gdmodule.c:993:5: warning: pointer targets in passing argument 5 of
'gdImageString' differ in signedness [-Wpointer-sign]
/sw/include/gd.h:141:6: note: expected 'unsigned char *' but argument
is of type 'char *'
_gdmodule.c: In function 'image_string16':
_gdmodule.c:1008:21: warning: passing argument 5 of 'gdImageString16'
from incompatible pointer type [enabled by default]
/sw/include/gd.h:143:6: note: expected 'short unsigned int *' but
argument is of type 'Py_UNICODE *'
_gdmodule.c: In function 'image_stringup':
_gdmodule.c:1022:5: warning: pointer targets in passing argument 5 of
'gdImageStringUp' differ in signedness [-Wpointer-sign]
/sw/include/gd.h:142:6: note: expected 'unsigned char *' but argument
is of type 'char *'
_gdmodule.c: In function 'image_stringup16':
_gdmodule.c:1037:23: warning: passing argument 5 of
'gdImageStringUp16' from incompatible pointer type [enabled by
default]
/sw/include/gd.h:144:6: note: expected 'short unsigned int *' but
argument is of type 'Py_UNICODE *'
_gdmodule.c: In function 'image_getclip':
_gdmodule.c:1173:5: warning: implicit declaration of function
'gdImageGetClip' [-Wimplicit-function-declaration]
_gdmodule.c: In function 'image_copyto':
_gdmodule.c:1218:28: warning: variable 'dh' set but not used
[-Wunused-but-set-variable]
_gdmodule.c:1218:25: warning: variable 'dw' set but not used
[-Wunused-but-set-variable]
_gdmodule.c: In function 'image_savealpha':
_gdmodule.c:1388:5: warning: implicit declaration of function
'gdImageSaveAlpha' [-Wimplicit-function-declaration]
_gdmodule.c: In function 'PyFileIfaceObj_IOCtx_GetBuf':
_gdmodule.c:1809:5: warning: passing argument 3 of
'PyString_AsStringAndSize' from incompatible pointer type [enabled by
default]
/Volumes/BigBackup/sage/sage-5.0.rc0/local/include/python2.7/stringobject.h:172:5:
note: expected 'Py_ssize_t *' but argument is of type 'int *'
_gdmodule.c: In function 'alloc_PyFileIfaceObj_IOCtx':
_gdmodule.c:1845:14: error: 'gdIOCtx' has no member named 'gd_free'
_gdmodule.c:1845:5: warning: statement with no effect [-Wunused-value]
_gdmodule.c: In function 'free_PyFileIfaceObj_IOCtx':
_gdmodule.c:1856:14: error: 'gdIOCtx' has no member named 'gd_free'
_gdmodule.c:1856:22: error: called object '<erroneous-expression>' is
not a function
_gdmodule.c:1856:5: warning: statement with no effect [-Wunused-value]
_gdmodule.c: In function 'init_gd':

_gdmodule.c:2177:28: error: 'gdAntiAliased' undeclared (first use in
this function)
_gdmodule.c:2177:28: note: each undeclared identifier is reported only
once for each function it appears in

(sage-sh) robert@ombre:src$

http://sage.math.washington.edu/home/robertwb/sage-5.0.rc0-logs/_gdmodule.i

[Robert Bradshaw]

Yep.

$ ./sage -i spkg/standard/pil-1.1.6.p4.spkg
Calling sage-spkg on 'spkg/standard/pil-1.1.6.p4.spkg'
...
Writing /Volumes/BigBackup/sage/sage-5.0.rc0/local/lib/python2.7/site-packages/PIL/PIL-1.1.6-py2.7.egg-info
creating /Volumes/BigBackup/sage/sage-5.0.rc0/local/lib/python2.7/site-packages/PIL.pth
real 0m37.797s
user 0m26.836s
sys 0m9.037s
Successfully installed pil-1.1.6.p4
Deleting temporary build directory
/Volumes/BigBackup/sage/sage-5.0.rc0/spkg/build/pil-1.1.6.p4
Making Python scripts relocatable...
Making pilconvert.py script relocatable
Making pildriver.py script relocatable
Making pilfile.py script relocatable
Making pilprint.py script relocatable
Finished installing pil-1.1.6.p4.spkg

[Dima Pasechnik]

built and all testslong passed on MacOSX 10.5.8 PPC (G4).

On Wednesday, May 2, 2012 7:03:14 AM UTC, Jeroen Demeyer 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

[Harald Schilly]

On Wednesday, May 2, 2012 9:03:14 AM UTC+2, Jeroen Demeyer wrote:

Dear Sage lovers,

We're releasing Sage 5.0.rc0.

building went fine, but some tests fail on my machine. it's a intel 32bit, Ubuntu 10.04.4 LTS.

$  sage -t  --long -force_lib devel/sage/sage/tests/cmdline.py # 1 doctests failed

sage -t --long -force_lib "devel/sage/sage/tests/cmdline.py"

**********************************************************************

File "/scratch/scratch/schilly/sage/sage-5.0.rc0/devel/sage/sage/tests/cmdline.py", line 270:

    sage: ret

Expected:

    0

Got:

    128

**********************************************************************

File "/scratch/scratch/schilly/sage/sage-5.0.rc0/devel/sage/sage/tests/cmdline.py", line 272:

    sage: out.find("All tests passed!") >= 0

Expected:

    True

Got:

    False

**********************************************************************

File "/scratch/scratch/schilly/sage/sage-5.0.rc0/devel/sage/sage/tests/cmdline.py", line 275:

    sage: ret

Expected:

    0

Got:

    128

**********************************************************************

File "/scratch/scratch/schilly/sage/sage-5.0.rc0/devel/sage/sage/tests/cmdline.py", line 277:

    sage: out.find("All tests passed!") >= 0

Expected:

    True

Got:

    False

**********************************************************************

1 items had failures:

   4 of 186 in __main__.example_1

***Test Failed*** 4 failures.

For whitespace errors, see the file /users/schilly/.sage//tmp/cmdline_10308.py

         [65.9 s]

[Dima Pasechnik]

hmm, it should be 42 rather than 128...

[Jeroen Demeyer]

The problem is /sw/include which contains a different version of gd.
Which should patch gdmodule such that it doesn't look in that directory.

[Dima Pasechnik]

On Friday, 4 May 2012 23:03:09 UTC+8, Jeroen Demeyer wrote:

The problem is /sw/include which contains a different version of gd.
Which should patch gdmodule such that it doesn't look in that directory.

IMHO /sw with fink's stuff is not something we allow on MacOSX, unless I am as usual

horribly misinformed.

Dima

[Robert Bradshaw]

On Fri, May 4, 2012 at 9:53 AM, Dima Pasechnik <dim...@gmail.com> wrote:
>
>
> On Friday, 4 May 2012 23:03:09 UTC+8, Jeroen Demeyer wrote:
>>
>> The problem is /sw/include which contains a different version of gd.
>> Which should patch gdmodule such that it doesn't look in that directory.

Ah hah.

> IMHO /sw with fink's stuff is not something we allow on MacOSX, unless I am
> as usual horribly misinformed.

True. But we shouldn't be picking anything up from there by default,
right? Looks like gdmodule explicitly adds /sw/ to its lib/include
paths.

[Michael Anselmi]

Build completed successfully and all long tests passed on Ubuntu 12.04.

Linux 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

[Robert Bradshaw]

Fixing gdmodule to not explicitly look in /sw/ seems to have done the
trick... builds fine, still running tests.

[Marshall Hampton]

All tests passed for 5.0.rc0 on an i7-3930k system running Kubuntu
11.10.

uname -a
Linux AVA-376751 3.0.0-19-generic #33-Ubuntu SMP Thu Apr 19 19:05:14

UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

-Marshall

On May 2, 2:03 am, Jeroen Demeyer <jdeme...@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.r...

[Jason Grout]

On 5/2/12 2:03 AM, Jeroen Demeyer 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.

I usually set the SAGE_MATPLOTLIB_GUI=yes environment variable to enable
native GUIs with matplotlib. With 5.0.rc0, I have a build problem on
OSX 10.6.8. At the top of the install.log, I have "Installing GCC
because you have gcc version 4.2.1, which is quite old.". The failure is:

building 'matplotlib.backends._macosx' extension
gcc -fno-strict-aliasing -fwrapv -DNDEBUG -g -fwrapv -O3 -Wall
-DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
-I/Users/grout/sage-trees/sage-5.0.rc0/loca
l/lib/python2.7/site-packages/numpy/core/include
-I/Users/grout/sage-trees/sage-5.0.rc0/local/include -I.
-I/Users/grout/sage-trees/sage-5.0.rc0/local/lib/python2.7/si
te-packages/numpy/core/include -Isrc -Iagg24/include -I.
-I/Users/grout/sage-trees/sage-5.0.rc0/local/include/python2.7 -c
src/_macosx.m -o build/temp.macosx-10.6-x86_
64-2.7/src/_macosx.o
gcc: error: src/_macosx.m: Objective-C compiler not installed on this system

error: command 'gcc' failed with exit status 1

Error building matplotlib package.

real 1m12.131s
user 1m2.038s
sys 0m4.963s
************************************************************************
Error installing package matplotlib-1.1.0
************************************************************************
Please email sage-devel (http://groups.google.com/group/sage-devel)
explaining the problem and including the relevant part of the log file
/Users/grout/sage-trees/sage-5.0.rc0/spkg/logs/matplotlib-1.1.0.log
Describe your computer, operating system, etc.
If you want to try to fix the problem yourself, *don't* just cd to
/Users/grout/sage-trees/sage-5.0.rc0/spkg/build/matplotlib-1.1.0 and
type 'make' or whatever is appropriate.
Instead, the following commands setup all environment variables
correctly and load a subshell for you to debug the error:
(cd
'/Users/grout/sage-trees/sage-5.0.rc0/spkg/build/matplotlib-1.1.0' &&
'/Users/grout/sage-trees/sage-5.0.rc0/sage' -sh)
When you are done debugging, you can type "exit" to leave the subshell.
************************************************************************
make[1]: *** [installed/matplotlib-1.1.0] Error 1

real 98m52.248s
user 73m19.981s
sys 13m51.748s
Error building Sage.

Any ideas or comments?

Thanks,

Jason

[Jeroen Demeyer]

On 2012-05-05 09:47, Robert Bradshaw wrote:
> Fixing gdmodule to not explicitly look in /sw/ seems to have done the
> trick... builds fine, still running tests.

Created
http://trac.sagemath.org/sage_trac/ticket/12909

[Jeroen Demeyer]

On 2012-05-05 21:51, Jason Grout wrote:
> Any ideas or comments?
The problem is that matplotlib assumes that "gcc" is an Objective-C
compiler, which is not the case within Sage. The environment variable
$OBJC (analogous to $CC and $CXX) should be used to determine the
Objective-C compiler, which apparently doesn't happen.

[Florent Hivert]

Hi,

> 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.

On openSUSE 12.1 (x86_64), make ptestlong reported:


The following tests failed:

sage -t --long -force_lib devel/sage/sage/tests/cmdline.py # 1 doctests failed
----------------------------------------------------------------------

The failure is:

sage -t --long -force_lib devel/sage/sage/tests/cmdline.py
**********************************************************************

File "/home/data/Sage-Install/sage-5.0.rc0/devel/sage-main/sage/tests/cmdline.py", l
ine 314:
sage: err
Expected:
''
Got:
'WARNING: Configuration file ipythonrc not found. Ignoring request.\n-----------
-------------------------------------------------\nTraceback (most recent call last)
:\n File "/home/data/Sage-Install/sage-5.0.rc0/local/lib/python/site-packages/IPyth
on/ConfigLoader.py", line 66, in load\n fname = filefind(fname,incpath)\n File "
/home/data/Sage-Install/sage-5.0.rc0/local/lib/python/site-packages/IPython/genutils
.py", line 554, in filefind\n \' not found in current or supplied directories:\'
+ `alt_dirs`\nIOError: File\'ipythonrc\' not found in current or supplied directorie
s:u\'/home/florent/.ipython\'\n\nWARNING: Problems loading configuration file \'ipyt
honrc\'\nStarting with default -bare bones- configuration.\n'

**********************************************************************
1 items had failures:

1 of 186 in __main__.example_1
***Test Failed*** 1 failures.

Cheers,

Florent

[Keshav Kini]

On Sun, May 6, 2012 at 6:22 AM, Florent Hivert <Florent...@lri.fr> wrote:
> The following tests failed:
>
>        sage -t  --long -force_lib devel/sage/sage/tests/cmdline.py # 1 doctests failed
> ----------------------------------------------------------------------
>
> The failure is:
>
> sage -t  --long -force_lib devel/sage/sage/tests/cmdline.py
> **********************************************************************
> File "/home/data/Sage-Install/sage-5.0.rc0/devel/sage-main/sage/tests/cmdline.py", l
> ine 314:
>    sage: err
> Expected:
>    ''
> Got:
>    'WARNING: Configuration file ipythonrc not found. Ignoring request.\n-----------

As Andrew mentioned earlier - in a different thread, it seems - this
happens when you have run a newer version of IPython on your system
and it has done some stuff in ~/.ipython which the Sage IPython, being
old, doesn't know what to do with.

[John H Palmieri]

On Saturday, May 5, 2012 4:45:51 PM UTC-7, Keshav Kini wrote:

On Sun, May 6, 2012 at 6:22 AM, Florent Hivert wrote:
> The following tests failed:
>
>        sage -t  --long -force_lib devel/sage/sage/tests/cmdline.py # 1 doctests failed
> ----------------------------------------------------------------------
>
> The failure is:
>
> sage -t  --long -force_lib devel/sage/sage/tests/cmdline.py
> **********************************************************************
> File "/home/data/Sage-Install/sage-5.0.rc0/devel/sage-main/sage/tests/cmdline.py", l
> ine 314:
>    sage: err
> Expected:
>    ''
> Got:
>    'WARNING: Configuration file ipythonrc not found. Ignoring request.\n-----------

As Andrew mentioned earlier - in a different thread, it seems - this
happens when you have run a newer version of IPython on your system
and it has done some stuff in ~/.ipython which the Sage IPython, being
old, doesn't know what to do with.

Why is Sage's IPython picking up files from ~/.ipython? Perhaps we should set IPYTHONDIR and/or IPYTHONRC in sage-env? Is there any reason not to do that? If that's a bad idea, then instead we should run the function "sage_setup" in spkg/bin/sage when the "ipython" argument is detected (or the "gdb-ipython" argument), which sets those variables temporarily.

--
John

[Keshav Kini]

On Sun, May 6, 2012 at 8:24 AM, John H Palmieri <jhpalm...@gmail.com> wrote:
> Why is Sage's IPython picking up files from ~/.ipython?

The same reason that Sage's Mercurial picks up ~/.hgrc, I guess,
whatever that may be. Or that Sage's GAP picks up ~/.gaprc ... are
there others?

[John H Palmieri]

On Saturday, May 5, 2012 5:31:08 PM UTC-7, Keshav Kini wrote:

On Sun, May 6, 2012 at 8:24 AM, John H Palmieri wrote:
> Why is Sage's IPython picking up files from ~/.ipython?

The same reason that Sage's Mercurial picks up ~/.hgrc, I guess,
whatever that may be. Or that Sage's GAP picks up ~/.gaprc ... are
there others?

But we go to the trouble to create ~/.sage/ipython/ and populate it with various ipythonrc files. Should Sage's IPython use those, the way Sage's matplotlib uses files in ~/.sage/matplotlib-1.1.0/ (the name of which includes the version number specifically to avoid incompatibilities among different versions, by the way)?

--
John

[John H Palmieri]

Another option: before running the test in tests/cmdline.py, we could set IPYTHONDIR and IPYTHONRC to avoid this problem.

--
John

[leif]

Keshav Kini wrote:
> On Sun, May 6, 2012 at 8:24 AM, John H Palmieri<jhpalm...@gmail.com> wrote:
>> Why is Sage's IPython picking up files from ~/.ipython?
>
> The same reason that Sage's Mercurial picks up ~/.hgrc, I guess,
> whatever that may be. Or that Sage's GAP picks up ~/.gaprc ... are
> there others?

Sure; e.g. ECL.

[John H Palmieri]

On Saturday, May 5, 2012 6:20:57 PM UTC-7, John H Palmieri wrote:

Another option: before running the test in tests/cmdline.py, we could set IPYTHONDIR and IPYTHONRC to avoid this problem.

See <http://trac.sagemath.org/sage_trac/ticket/12911>.  Does this patch fix the problem?

--
John

[Alexander Dreyer]

Hi!
built and made ptestlong sucessfully on SuSE Enterprise 11.

But I had to hack mpir to accept gcc 4.3.2 64bits: configure had
hard-coded not to build on this platform, because the original gcc 4.3.2
was buggy, but mine is patched. (The mpir guys do not test the actual
bug, but just look for gcc's version.)

Best regards,
Alexander

Am 02.05.2012 09:03, schrieb 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]
>

--
Dr. rer. nat. Dipl.-Math. Alexander Dreyer

Abteilung "Systemanalyse, Prognose und Regelung"
Fraunhofer Institut f�r Techno- und Wirtschaftsmathematik (ITWM)
Fraunhofer-Platz 1
67663 Kaiserslautern

Telefon +49 (0) 631-31600-4318
Fax +49 (0) 631-31600-1099
E-Mail alexande...@itwm.fraunhofer.de
Internet http://www.itwm.fraunhofer.de/sys/dreyer.html

[Jeroen Demeyer]

On 2012-05-06 23:22, Alexander Dreyer wrote:
> Hi!
> built and made ptestlong sucessfully on SuSE Enterprise 11.
>
> But I had to hack mpir to accept gcc 4.3.2 64bits: configure had
> hard-coded not to build on this platform, because the original gcc 4.3.2
> was buggy, but mine is patched. (The mpir guys do not test the actual
> bug, but just look for gcc's version.)

I agree, hardcoding that bad version isn't a good idea. Also because
MPIR might just work well enough to build GCC.

[gsw]

Under OS X 10.4.11 (on an Intel "Core2Duo" CPU system) with XCode 2.5 (the latest available for OS X 10.4), Sage-5.0.rc0 built fine, and "make ptestlong" passed all tests.

Cheers,
Georg

[Johan S. R. Nielsen]

Builds fine and all tests pass (make -testall), on Ubuntu 12.04,
x86_64, Linux 3.2.0-24-generic.
I have 4.8.alpha2 running as well which had to be coerced quite a bit
to compile on my system, including removing and installing various
packages; I have no idea whether this has an influence on 5.0rc0
build :)

Cheers,
Johan

[leif]

Turns out that apparently only Debian's GCC 4.3.2 is affected (not
vanilla FSF), and only if '-fstrict-aliasing' is enabled (which is the
case with '-O2'.)

See:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524472

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36765


So we should probably patch MPIR's 'configure'.

[Bill Hart]

Thanks for the information. I am forwarding this to mpir-devel to see
what Jason thinks about possibly disabling '-fstrict-aliasing'
upstream for builds on Debian gcc 4.3.2.

I wonder how much of a performance hit is involved.

Bill.

> --
> 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]

Bill Hart wrote:
> Thanks for the information. I am forwarding this to mpir-devel to see
> what Jason thinks about possibly disabling '-fstrict-aliasing'
> upstream for builds on Debian gcc 4.3.2.

Well, in Sage we'd mainly need to bypass the test (or add
'-fno-strict-aliasing') to bootstrap the GCC (4.6.3) spkg; after that's
been built, MPIR and MPFR are rebuilt with the new compiler.

For MPIR, it would probably make sense to add the test case from PR
36765, and if that fails, either bail out or work around the bug (with a
warning, by disabling strict aliasing).


-leif

[Jeroen Demeyer]

On 2012-05-05 21:51, Jason Grout wrote:

> building 'matplotlib.backends._macosx' extension
> gcc -fno-strict-aliasing -fwrapv -DNDEBUG -g -fwrapv -O3 -Wall
> -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1
> -I/Users/grout/sage-trees/sage-5.0.rc0/loca
> l/lib/python2.7/site-packages/numpy/core/include
> -I/Users/grout/sage-trees/sage-5.0.rc0/local/include -I.
> -I/Users/grout/sage-trees/sage-5.0.rc0/local/lib/python2.7/si
> te-packages/numpy/core/include -Isrc -Iagg24/include -I.
> -I/Users/grout/sage-trees/sage-5.0.rc0/local/include/python2.7 -c
> src/_macosx.m -o build/temp.macosx-10.6-x86_
> 64-2.7/src/_macosx.o
> gcc: error: src/_macosx.m: Objective-C compiler not installed on this
> system
> error: command 'gcc' failed with exit status 1
> Error building matplotlib package.

I had a closer look and don't see an obvious fix for this. Python's
distutils assumes that the C compiler can also compile Objective-C and
it looks non-trivial to change this. For the R spkg, we also needed an
Objective-C compiler on OS X. Since R respects the $OBJC environment
variable, this wasn't a problem.

The only feasible solution I see for Python packages is including an
Objective-C compiler in the GCC spkg (and then maybe only build it on OS X).