• solaris
• sage-3.2.3

Sage 3.2.3 on Solaris x86 build notes

Note: This page is outdated. Please check the main Solaris bit porting page for the current status.

Build Issues

With gfortran 4.2.4 the root finding code in numpy is broken among other things. This causes the following problems:

• numpy's root finding code segfaults when linked against ATLAS - no solution yet, but as a workaround build numpy without ATLAS support
• scipy's special functions like Ei(10) cause segfaults. This might also be Solaris vs. ATLAS related.

Using gfortran 4.3.x fixes the problem.

Fixes

Here are some patches for the fixes below:

• 3.2.3.final-solaris-fixes.patch

• 3.2.3.final-solaris-getrusage.patch

• 3.2.3.final-solaris-misc-fixes.patch

• 3.2.3.final-solaris-ell_rational_field.py-noise.patch (fixes the numerical noise issue)

Upgrade gnucrypt to 1.4.3 release to fix entropy issue

gnucrypt 1.4.0 needs too much entropy at startup - an upgrade to 1.4.3 fixes that. From the release notes of version 1.4.1 (2008-04-25):

  Fixed a bug introduced by 1.3.1 which led to the comsumption of far 
   too much entropy for the intial seeding.

sage-native-execute is using bashism

diff -r 396119818b99 sage-native-execute
--- a/sage-native-execute       Fri Jan 02 14:18:47 2009 -0800
+++ b/sage-native-execute       Thu Jan 08 03:15:44 2009 -0500
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/usr/bin/env bash
 
 export LD_LIBRARY_PATH=$SAGE_ORIG_LD_LIBRARY_PATH
 if [ `uname` = 'Darwin' ]; then

interface/singular.py pexpect hangs

Singular seems to be limited to about 180 characters via the pexpect interface. Applying this patch works around that limitation by using the file interface:

diff -r e69ceb84399b sage/interfaces/singular.py
--- a/sage/interfaces/singular.py       Fri Jan 02 23:01:05 2009 -0500
+++ b/sage/interfaces/singular.py       Sat Jan 10 13:29:09 2009 -0500
@@ -316,7 +316,7 @@
                         restart_on_ctrlc = True,
                         verbose_start = False,
                         logfile = logfile,
-                        eval_using_file_cutoff=1000)
+                        eval_using_file_cutoff=100)
         self.__libs  = []
         self._prompt_wait = prompt
         self.__to_clear = []   # list of variable names that need to be cleared.

William commented in IRC:

[9:28pm] wstein: mabs -- that singular pexpect fix -- you should make it only happen on solaris.
[9:28pm] mabs: yes
[9:28pm] wstein: Since there could be a big performance impact on other systems.
[9:28pm] wstein: I would do that by writing
[9:28pm] wstein: eval_using_file_cutoff=None
[9:28pm] mabs: I just put up dirty fixes on the wiki page
[9:28pm] wstein: then in the first line of code set it.
[9:28pm] wstein: Or use
[9:28pm] wstein: eval_using_file_cutoff=100 if is_solaris else 1000
[9:29pm] wstein: where is_solaris is whatever code says it's solaris.

NaN vs. nan and Infinity vs. inf in real_double.pyx

**********************************************************************
File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/real_double.pyx", line 1311:
    sage: RDF(0).log()
Expected:
    -inf
Got:
    -Infinity
**********************************************************************
File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/real_double.pyx", line 1313:
    sage: RDF(-1).log()
Expected:
    nan
Got:
    -NaN

This is fixed by the following patch since we now rely on GSL again instead of the underlying libc representation:

diff -r e69ceb84399b sage/rings/real_double.pyx
--- a/sage/rings/real_double.pyx        Fri Jan 02 23:01:05 2009 -0500
+++ b/sage/rings/real_double.pyx        Sat Jan 10 19:05:27 2009 -0500
@@ -1283,9 +1283,9 @@
     cdef _log_base(self, double log_of_base):
         if self._value < 2:
             if self._value == 0:
-                return -1./0
+                return RDF(-1)/RDF(0)
             if self._value < 0:
-                return 0./0
+                return RDF(0)/RDF(0)
             _sig_on
             a = self._new_c(gsl_sf_log_1plusx(self._value - 1) / log_of_base)
             _sig_off

nan vs. NaN in complex_double.pyx

**********************************************************************
File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/complex_double.pyx", line 895:
    sage: ~(0*CDF(0,1))
Expected:
    nan + nan*I
Got:
    -NaN + NaN*I
**********************************************************************

The following terrible hack fixes that problem:

diff -r e69ceb84399b sage/rings/complex_double.pyx
--- a/sage/rings/complex_double.pyx     Fri Jan 02 23:01:05 2009 -0500
+++ b/sage/rings/complex_double.pyx     Sat Jan 10 19:30:41 2009 -0500
@@ -789,7 +789,8 @@
             s = s+"%s*I"%y
         if len(s) == 0:
             s = "0"
-        return s
+        s_clean=s.replace("NaN","nan").replace("-nan","nan") 
+        return s_clean
 
     def _latex_(self):
         """

Numerical noise in sage/rings/qqbar.py

[4:36pm] mabs: cwitty: I have another interesting bug for you:
[4:36pm] mabs: File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/rings/qqbar.py", line 3826:
[4:36pm] mabs:     sage: cp.complex_roots(30, 1)
[4:36pm] mabs: Expected:
[4:36pm] mabs:     [1.189207115002721?,
[4:36pm] mabs:     -1.189207115002721?,
[4:36pm] mabs:     1.189207115002721?*I,
[4:36pm] mabs:     -1.189207115002721?*I]
[4:36pm] mabs: Got:
[4:36pm] mabs:     [1.189207115002721?, -1.189207115002722?, 1.189207115002721?*I, -1.189207115002721?*I]
[4:37pm] mabs: Notice that the second and third entries are different?
[4:37pm] mabs: Ehh, the second only
[4:38pm] cwitty: Yes.  It's probably not a bug; complex_roots doesn't guarantee to find the tightest possible 
interval, and it depends on ATLAS which doesn't guarantee identical results.
[4:38pm] mabs: ok
[4:38pm] mabs: Should I use "..." then?
[4:38pm] cwitty: Yes.

Here is a patch for the qqbar.py issue with a little explanation:

diff -r e69ceb84399b sage/rings/qqbar.py
--- a/sage/rings/qqbar.py       Fri Jan 02 23:01:05 2009 -0500
+++ b/sage/rings/qqbar.py       Sat Jan 10 19:47:10 2009 -0500
@@ -3823,9 +3823,13 @@
         EXAMPLES:
             sage: x = polygen(ZZ)
             sage: cp = AA.common_polynomial(x^4 - 2)
+
+        Note that the precision is not guaraneteed to find the tightest possible interval 
+        since complex_roots() depends on the underlying BLAS implementation.
+
             sage: cp.complex_roots(30, 1)
             [1.189207115002721?,
-             -1.189207115002721?,
+             -1.18920711500272...?,
              1.189207115002721?*I,
              -1.189207115002721?*I]
         """

• Other fixes to the Sage library: 3.2.3.final-solaris-fixes.patch, 3.2.3.final-solaris-getrusage-.patch

sympow FPU 53 bit control word setup

Sympow only works when the FPU control word is set to 53 bit rounding precision. The following code is a x86 compatible version of fpu.c of Sympow:

void fpu_53bits()
{
printf("Setting cpu control word\n");
 unsigned short _ncw = (0x027f);
__asm__ __volatile__ ("fldcw %0" : : "m" (*&_ncw));
}

Note that this needs to be guarded by the usual flags for x86 and amd64 Solaris. The complete list of fixes required:

• add i86pc
• make x86 check independent of Linux or add Solaris/x86 specific fpu.c section
• -O3 to -O1 seems to core dump on Solaris/x86, -O0 seems to work

This fixes two doctests:

        sage -t  "devel/sage/sage/modular/abvar/abvar.py"
        sage -t  "devel/sage/sage/lfunctions/sympow.py"

Numerical Noise in point counting code (schemes/elliptic_curves/ell_rational_field.py)

The problem is that the inital bound is different:

<     initial bound 2.62270974833656e117
---
>     initial bound 2.62270974833657e117

In its full glory:

sage -t  "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py"
**********************************************************************
File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py", line 4640:
    sage: a=E.S_integral_points(S=[2,3], mw_base=[P1,P2,P3], verbose=True);a
Expected:
    max_S: 3 len_S: 3 len_tors: 1
    lambda 0.485997517468...
    k1,k2,k3,k4 6.68597129142710e234 1.31952866480763 3.31908110593519e9 2.42767548272846e17
    mw_base [(1 : -1 : 1), (2 : 0 : 1), (0 : -3 : 1)]
    mw_base_log [0.667789378224099, 0.552642660712417, 0.818477222895703]
    mp [5, 7]
    mw_base_p_log [[2^2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^14 + 2^15 + 2^18 + 2^19 + O(2^20), 2^2 + 2^3 + 2^5 + 2^6 + 2^9 + 2^11 + 2^12 + 2^14 + 2^15 + 2^16 + 2^18 + O(2^20), 2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^11 + 2^12 + 2^13 + 2^16 + 2^17 + 2^19 + O(2^20)], [2*3^2 + 2*3^5 + 2*3^6 + 2*3^7 + 3^8 + 3^9 + 2*3^10 + 3^12 + 2*3^14 + 3^15 + 3^17 + 2*3^19 + O(3^20), 2*3 + 2*3^2 + 2*3^3 + 2*3^4 + 2*3^6 + 2*3^7 + 2*3^8 + 3^10 + 2*3^12 + 3^13 + 2*3^14 + 3^15 + 3^18 + O(3^20), 3 + 3^2 + 2*3^3 + 3^6 + 2*3^7 + 2*3^8 + 3^9 + 2*3^11 + 2*3^12 + 2*3^13 + 3^15 + 2*3^16 + 3^18 + 2*3^19 + O(3^20)]]
    k5,k6,k7 0.321154513240... 1.55246328915... 0.161999172489...
    initial bound 2.62270974833657e117
    bound_list [58, 58, 58]
    bound_list [8, 9, 9]
    bound_list [8, 7, 7]
    bound_list [8, 7, 7]
    starting search of points using coefficient bound  8
    x-coords of S-integral points via linear combination of mw_base and torsion:
    [-3, -26/9, -8159/2916, -2759/1024, -151/64, -1343/576, -2, -7/4, -1, -47/256, 0, 1/4, 4/9, 9/16, 58/81, 7/9, 6169/6561, 1, 17/16, 2, 33/16, 172/81, 9/4, 25/9, 3, 31/9, 4, 25/4, 1793/256, 8, 625/64, 11, 14, 21, 37, 52, 6142/81, 93, 4537/36, 342, 406, 816, 207331217/4096]
    starting search of extra S-integer points with absolute value bounded by 3.89321964979420
    x-coords of points with bounded absolute value
    [-3, -2, -1, 0, 1, 2]
    Total number of S-integral points: 43
    [(-3 : 0 : 1), (-26/9 : 28/27 : 1), (-8159/2916 : 233461/157464 : 1), (-2759/1024 : 60819/32768 : 1), (-151/64 : 1333/512 : 1), (-1343/576 : 36575/13824 : 1), (-2 : 3 : 1), (-7/4 : 25/8 : 1), (-1 : 3 : 1), (-47/256 : 9191/4096 : 1), (0 : 2 : 1), (1/4 : 13/8 : 1), (4/9 : 35/27 : 1), (9/16 : 69/64 : 1), (58/81 : 559/729 : 1), (7/9 : 17/27 : 1), (6169/6561 : 109871/531441 : 1), (1 : 0 : 1), (17/16 : -25/64 : 1), (2 : 0 : 1), (33/16 : 17/64 : 1), (172/81 : 350/729 : 1), (9/4 : 7/8 : 1), (25/9 : 64/27 : 1), (3 : 3 : 1), (31/9 : 116/27 : 1), (4 : 6 : 1), (25/4 : 111/8 : 1), (1793/256 : 68991/4096 : 1), (8 : 21 : 1), (625/64 : 14839/512 : 1), (11 : 35 : 1), (14 : 51 : 1), (21 : 95 : 1), (37 : 224 : 1), (52 : 374 : 1), (6142/81 : 480700/729 : 1), (93 : 896 : 1), (4537/36 : 305425/216 : 1), (342 : 6324 : 1), (406 : 8180 : 1), (816 : 23309 : 1), (207331217/4096 : 2985362173625/262144 : 1)]
Got:
    max_S: 3 len_S: 3 len_tors: 1
    lambda 0.485997517468082
    k1,k2,k3,k4 6.68597129142710e234 1.31952866480763 3.31908110593519e9 2.42767548272846e17
    mw_base [(1 : -1 : 1), (2 : 0 : 1), (0 : -3 : 1)]
    mw_base_log [0.667789378224099, 0.552642660712417, 0.818477222895703]
    mp [5, 7]
    mw_base_p_log [[2^2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^14 + 2^15 + 2^18 + 2^19 + O(2^20), 2^2 + 2^3 + 2^5 + 2^6 + 2^9 + 2^11 + 2^12 + 2^14 + 2^15 + 2^16 + 2^18 + O(2^20), 2 + 2^3 + 2^6 + 2^7 + 2^8 + 2^9 + 2^11 + 2^12 + 2^13 + 2^16 + 2^17 + 2^19 + O(2^20)], [2*3^2 + 2*3^5 + 2*3^6 + 2*3^7 + 3^8 + 3^9 + 2*3^10 + 3^12 + 2*3^14 + 3^15 + 3^17 + 2*3^19 + O(3^20), 2*3 + 2*3^2 + 2*3^3 + 2*3^4 + 2*3^6 + 2*3^7 + 2*3^8 + 3^10 + 2*3^12 + 3^13 + 2*3^14 + 3^15 + 3^18 + O(3^20), 3 + 3^2 + 2*3^3 + 3^6 + 2*3^7 + 2*3^8 + 3^9 + 2*3^11 + 2*3^12 + 2*3^13 + 3^15 + 2*3^16 + 3^18 + 2*3^19 + O(3^20)]]
    k5,k6,k7 0.321154513240167 1.55246328915541 0.161999172489361
    initial bound 2.62270974833656e117
    bound_list [58, 58, 58]
    bound_list [8, 9, 9]
    bound_list [8, 7, 7]
    bound_list [8, 7, 7]
    starting search of points using coefficient bound  8
    x-coords of S-integral points via linear combination of mw_base and torsion:
    [-3, -26/9, -8159/2916, -2759/1024, -151/64, -1343/576, -2, -7/4, -1, -47/256, 0, 1/4, 4/9, 9/16, 58/81, 7/9, 6169/6561, 1, 17/16, 2, 33/16, 172/81, 9/4, 25/9, 3, 31/9, 4, 25/4, 1793/256, 8, 625/64, 11, 14, 21, 37, 52, 6142/81, 93, 4537/36, 342, 406, 816, 207331217/4096]
    starting search of extra S-integer points with absolute value bounded by 3.89321964979420
    x-coords of points with bounded absolute value
    [-3, -2, -1, 0, 1, 2]
    Total number of S-integral points: 43
    [(-3 : 0 : 1), (-26/9 : 28/27 : 1), (-8159/2916 : 233461/157464 : 1), (-2759/1024 : 60819/32768 : 1), (-151/64 : 1333/512 : 1), (-1343/576 : 36575/13824 : 1), (-2 : 3 : 1), (-7/4 : 25/8 : 1), (-1 : 3 : 1), (-47/256 : 9191/4096 : 1), (0 : 2 : 1), (1/4 : 13/8 : 1), (4/9 : 35/27 : 1), (9/16 : 69/64 : 1), (58/81 : 559/729 : 1), (7/9 : 17/27 : 1), (6169/6561 : 109871/531441 : 1), (1 : 0 : 1), (17/16 : -25/64 : 1), (2 : 0 : 1), (33/16 : 17/64 : 1), (172/81 : 350/729 : 1), (9/4 : 7/8 : 1), (25/9 : 64/27 : 1), (3 : 3 : 1), (31/9 : 116/27 : 1), (4 : 6 : 1), (25/4 : 111/8 : 1), (1793/256 : 68991/4096 : 1), (8 : 21 : 1), (625/64 : 14839/512 : 1), (11 : 35 : 1), (14 : 51 : 1), (21 : 95 : 1), (37 : 224 : 1), (52 : 374 : 1), (6142/81 : 480700/729 : 1), (93 : 896 : 1), (4537/36 : 305425/216 : 1), (342 : 6324 : 1), (406 : 8180 : 1), (816 : 23309 : 1), (207331217/4096 : 2985362173625/262144 : 1)]
**********************************************************************

Doctest Failures/Leads for other Bugs

• More details coming soon - about 30 doctests failed, but about 15 to 20 are fixable with little effort

axes.py: name 'NaN' is not defined

We are seeing three doctest failures in

• sage -t "devel/sage/sage/symbolic/expression.pyx"
• sage -t "devel/sage/sage/coding/code_bounds.py"
• sage -t "devel/sage/sage/plot/plot.py"

File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/devel/sage/sage/plot/plot.py", line 1557:
    sage: plot(x^(1/3), (x,-1,1))
Exception raised:
    Traceback (most recent call last):
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/bin/ncadoctest.py", line 1231, in run_one_test
        self.run_one_example(test, example, filename, compileflags)
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/bin/sagedoctest.py", line 38, in run_one_example
        OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/bin/ncadoctest.py", line 1172, in run_one_example
        compileflags, 1) in test.globs
      File "<doctest __main__.example_36[33]>", line 1, in <module>
        plot(x**(Integer(1)/Integer(3)), (x,-Integer(1),Integer(1)))###line 1557:
    sage: plot(x^(1/3), (x,-1,1))
      File "sage_object.pyx", line 92, in sage.structure.sage_object.SageObject.__repr__ (sage/structure/sage_object.c:1082)
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/plot.py", line 712, in _repr_
        self.show()
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/plot.py", line 1066, in show
        hgridlinesstyle=hgridlinesstyle)
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/plot.py", line 1317, in save
        xmin, xmax, ymin, ymax = sage_axes.add_xy_axes(subplot, xmin, xmax, ymin, ymax)
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/axes.py", line 325, in add_xy_axes
        x_axis_ypos, ystep, ytslminor, ytslmajor = self._find_axes(ymin, ymax)
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/axes.py", line 241, in _find_axes
        tslmajor, oppaxis, step = self._tasteful_ticks(minval, maxval)
      File "/home/mabshoff/build-3.2.3.final/sage-3.2.3.final-fulvia/local/lib/python2.5/site-packages/sage/plot/axes.py", line 131, in _tasteful_ticks
        d0 = eval(sl[0])
      File "<string>", line 1, in <module>
    NameError: name 'NaN' is not defined

The following code snippet illustrates the problem:

#include "stdio.h"
#include "math.h"

int main () {
 printf("pow: %d\n",pow(-0.5, 0.33333));
}

It returns 1 on Linux, 0 on Solaris - see "man pow" on Solaris 10:

     These functions compute the value of x raised to  the  power
     y, x**y. If x is negative, y must be an integer value.

Thanks to Carl Witty for helping this track down.

Note that a potential solution to this problem is to check out what python does for pow().

Other Annoyances

• -sdist as well as -bdist is seriously broken with BSD-ish shell utils installed in the default path on Solaris