Robert Bradshaw wrote:
On Jan 14, 2010, at 9:49 PM, Robert Bradshaw wrote:
On Jan 14, 2010, at 5:46 PM, Dr. David Kirkby wrote:
Dr. David Kirkby wrote:
I tried to build sage-4.3.1.alpha2 in 32-bit mode on a Sun Blade
2000. I've installed Sage on that several times before without
issue. But this time I get an error.
This is a bit annoying, as I really did believe that 4.3.1 would
build on Solaris 10 SPARC without any problems, after the issues
with Sage picking up the wrong compiler were finally resolved. The
output below shows this.
There is by the way a build in progress on 't2' at
/rootpool2/local/kirkby/sage-4.3.1.alpha2
however, since 't2' is not exactly fast, it has not yet reached the
point of failure. The last bit built as I write is
matplotlib-0.99.1.p3.
The build on 't2' has now failed at the same point. This is now
http://trac.sagemath.org/sage_trac/ticket/7932
which I marked as a blocker, as this new bug prevents Sage building
on Solaris 10. Sun provided the T5240 free, and want to see Sage
running on it. We can produce a 4.3.1 which builds on Solaris 10, as
all the bugs are resolved - until a new one was introduced.
It looks like this is due to a change in Cython--its test suite finds
the error on t2. (Unfortunately I guess no one did any testing on
Solaris before the last release). I'm not understanding why there is a
problem though. See the file at
http://sage.math.washington.edu/home/robertwb/solaris/simple_complex.c
which compiles without even a warning on boxen, but not on t2.
rober...@t2:~/solaris$ gcc simple_complex.c
simple_complex.c: In function '__pyx_t_double_complex_from_parts':
simple_complex.c:20: error: '_Complex_I' undeclared (first use in this
function)
simple_complex.c:20: error: (Each undeclared identifier is reported
only once
simple_complex.c:20: error: for each function it appears in.)
According to the documentation at
http://www.opengroup.org/onlinepubs/009695399/basedefs/complex.h.html
The <complex.h> header shall define the following macros:
complex
Expands to _Complex.
_Complex_I
Expands to a constant expression...
so the complex.h on t2 is somehow broken. Even stranger,
#if defined(_Complex_I)
evaluates to TRUE, but then it complains that _Complex_I is not
defined. I'm really not sure how to "fix" this 'cause it looks like a
buggy compiler/headers, not broken code.
Looks like we're not the first ones to run into this:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6549313
- Robert
Em, I'm puzzled by this too. It builds fine with the Sun compiler
kir...@t2:[~] $ /opt/SUNWspro/bin/cc simple_complex.c
kir...@t2:[~] $ ./a.out
CYTHON_CCOMPLEX 1
but not with gcc.
kir...@t2:[~] $ gcc -Wall simple_complex.c
simple_complex.c: In function '__pyx_t_double_complex_from_parts':
simple_complex.c:20: error: '_Complex_I' undeclared (first use in this function)
simple_complex.c:20: error: (Each undeclared identifier is reported only once
simple_complex.c:20: error: for each function it appears in.)
I've tested on both t2 (SPARC processors, Solaris 10) and a Sun Ultra 27 (Intel
Xeon, Open Solaris 06/2009)
In all cases, it fails with gcc but builds with the Sun compiler.
I'll report this as a gcc bug, as that would seem the most likely reason.
Dave
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
