#6456: Upgrade cvxopt in sage from 0.9 to 1.1.2
--------------------------------+-------------------------------------------
Reporter: was | Owner: mabshoff
Type: defect | Status: needs_work
Priority: major | Milestone: sage-4.5.2
Component: packages | Keywords:
Author: schilly, dimpase | Upstream: Completely fixed; Fix reported
upstream
Reviewer: | Merged:
Work_issues: |
--------------------------------+-------------------------------------------
Comment(by drkirkby):
I set about trying to resolve why cvxopt would build on some Solaris
systems but not on others. I believe I have finally got to the bottom of
this.
If one looks in the current cvxopt SPKG.txt file, there is a reference to
this bug, and why the sun_complex.h was added.
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6549313
which does not appear to have any activity for more than 3 years. There's
a little test program there, which I modified a bit to print good or bad:
{{{
#include <stdio.h>
#include <complex.h>
/*
* "volatile" is meant to prevent gcc from calculating the sqrt as a
* constant, we want to test libc.
*/
volatile complex double z = -_Complex_I;
int
main(void)
{
z = csqrt(z);
if (creal(z) > 0.0)
printf("good\n"); /* good */
else
printf("bad\n"); /* bad */
}
}}}
After saving that to a file {{{test.c}}} I then tried to compile this
using
{{{
gcc -lm -std=c99 test.c # Or in some cases using the Sun compiler.
}}}
in each case noting if the file compiled, or whether it gave an error
like:
{{{
$ gcc -lm -std=c99 test.c
test.c:8: error: '_Complex_I' undeclared here (not in a function)
}}}
Assuming it did compile (which was the minority of cases), if that test
program printed 'good' or 'bad' when it was run.
Comparing different 12 systems I have access to, '''sorted in order of the
release date''' of the operating system, this is what I found:
||'''Computer'''||'''CPU'''||'''hostname'''||'''OS'''||'''Release of
OS'''||'''Compiler'''||'''Compile'''||'''Result''||
||Sun Blade 2000||SPARC||swan||Solaris 10||10/2009||gcc 4.5.0||Yes||Good||
||Sun Blade 2000||SPARC||swan||Solaris 10||10/2009||!SunStudio
12.1||Yes||Bad||
||Sun Blade 2000||SPARC||swan||Solaris 10||10/2009||gcc 4.4.4||No||-||
||Sun Blade 2000||SPARC||swan||Solaris 10||10/2009||gcc 3.4.3||No||-||
||unknown ||x86||orcus||Solaris 10||10/2009||gcc 4.3.4||No||-||
||unknown ||x86||orcus||Solaris 10||10/2009||gcc 3.4.3||No||-||
||Sun Ultra 27||x86||hawk||!OpenSolaris||06/2009||!SunStudio
12.1||Yes||Good||
||Sun Ultra 27||x86||hawk||!OpenSolaris||06/2009||gcc 4.5.0||Yes||Good||
||Sun Ultra 27||x86||hawk||!OpenSolaris||06/2009||gcc 4.4.4||No||-||
||Sun Ultra 27||x86||hawk||!OpenSolaris||06/2009||gcc 3.4.3||No||-||
||Sun Blade 2500||SPARC||mercury||Solaris 10||05/2009||gcc 4.3.4||No||-||
||Sun Blade 2500||SPARC||mercury||Solaris 10||05/2009||gcc 3.4.5||No||-||
||Sun Blade 2500||SPARC||mercury||Solaris 10||05/2009||gcc 3.4.3||No||-||
||Sun T5240||SPARC||t2||Solaris 10||05/2009||gcc 4.4.1||No||-||
||Sun T5240||SPARC||t2||Solaris 10||05/2009||gcc 3.4.3||No||-||
||Sun Fire X4540||x86||disk||!OpenSolaris||11/2008||gcc 3.4.3||No||-||
||Dell !OptiPlex 755||x86||fulvia||Solaris 10||05/2008||gcc
4.5.0||Yes||Good||
||Dell !OptiPlex 755||x86||fulvia||Solaris 10||05/2008||gcc 3.4.3||No||-||
||Sun Blade 2500||SPARC||mark||Solaris 10||01/2006||gcc 4.5.0||Yes||Good||
||Sun Blade 2500||SPARC||mark||Solaris 10||01/2006||gcc 3.4.3||No||-||
||Sun Blade 2500||SPARC||mark||Solaris 10||01/2006||!SunStudio
12||Yes||Bad||
||Sun Blade 1000||SPARC||redstart||Solaris 10||03/2005||4.5.0||Yes||Good||
||Sun Blade 1000||SPARC||redstart||Solaris 10||03/2005||4.4.3||No||-||
||Sun Blade 1000||SPARC||redstart||Solaris 10||03/2005||3.4.3||No||-||
||Sun Netra T1||SPARC||kestrel||Solaris 10||03/2005||4.4.2||No||-||
||Sun Netra T1||SPARC||kestrel||Solaris 10||03/2005||3.4.3||No||-||
||Sun Fire 480R||SPARC||ra||Solaris 8||02/2004||gcc 4.3.4||No||-||
Notes:
* ''swan'' , ''redstart'' , ''hawk'' and ''kestrel'' are my own personal
machines.
* ''fulvia'', ''mark'' and ''mark2'' are hosts on Skynet.
* ''disk'' and ''t2'' are hosts on the *.math.washington.edu network.
* ''ra'' and ''mercury'' are hosts on blastwave.org. (Dennis Clark of
Blastwave has given me access to their network, which is useful, as their
Sun Blade 2500 has faster CPUs than the Sun Blade 2500 on Skynet).
* ''orcus'' is a Solaris zone running on some x86 hardware on the
blastwave.org network. I don't know what that hardware is - since it's in
a Solaris zone, this is hidden.
* ''ra'' on the blastwave.org network runs a version of Solaris older
than what Sage aims to support. IMHO, we should aim to support all Solaris
10 releases, the first of which was released in March 2005, but not bother
with older releases, where there are C99 related issues.
Looking at those results, some patterns can be seen.
* Every time gcc 4.5.0 was used, {{{test.c}}} compiled and run OK. (gcc
4.5.0 was available on all the skynet machines and I built it on all my
own machines. I did not bother building it on t2.math, disk.math or any of
the machines on Blastwave.)
* If an older version of gcc was used, {{{test.c}}} would never compile.
* Whether the system had SPARC or x86 processors did change the behavior.
* The age of the operating system did not matter. (Although I have some
doubts if this would have worked with gcc 4.5 on the old Solaris 8
machine, but as noted above, this is too old to bother supporting.)
I then realised that this is the same bug that hit us with the Sage
library before (#7932). I reported that to the gcc bug database as two
bugs - one for SPARC, one for x86. The GCC developers then closed one as a
duplicate of the other.
* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
If you read [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753 gcc bug
42753], it basically boils down to the fact that the gcc developers claim
it's a bug in the Sun header file, but that their ''fixincludes'' is
lacking the facility to deal with this. However, their ''fixincludes'' was
updated in gcc 4.5, so this problem was fixed in gcc 4.5.
So I suspect we have two options.
* Force people to use gcc 4.5 on Solaris, then remove the
{{{sun_complex.h}}} hack completely. That would be rather annoying, since
that's the latest version of gcc, and I'm not aware of anywhere where one
can download a pre-compiled gcc 4.5 binary. People would have to build it
themselves, which is a non-trivial process on Solaris.
* We apply that patch on gcc versions older than 4.5, but omit the patch
with gcc version 4.5 or later. There's an example of how to do this
[http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/cpp
/predefined-macros.html here] using the gcc macros {{{__GNUC__}}},
{{{__GNUC_MINOR__}}} and {{{__GNUC_PATCHLEVEL__}}}. It's easy to see what
macros gcc defines, by creating an empty file {{{foobar.c}}}, and using
{{{gcc -c -E -dM foobar.c}}}
So in summary, I think the solution to the Solaris problem is that the
code in cvxopt needs changing so that the patched header only gets
included when building with gcc less than 4.5.0. I suspect the easiest
solution is to always apply a patched header file, but arrange for the
patch to just include {{{<complex.h>}}} on gcc 4.5.0 or later, but have
its current behavior on earlier gcc series.
Although I've not yet modified {{{sun_complex.h}}} to have this behavior,
I suspect it will allow the code to compile on any gcc >= 4.0.1, which is
the earliest Sage supports.
Dave
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6456#comment:85>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
