Differences between revisions 21 and 22
Revision 21 as of 2009-01-17 09:28:45
Size: 20315
Comment: elaborate more on the ctypes situation
Revision 22 as of 2009-01-17 13:23:08
Size: 19940
Comment: add clean fix for gdb on OSX issue
Deletions are marked like this. Additions are marked like this.
Line 388: Line 388:
The above problem is caused by the IPython import. See also http://mail.python.org/pipermail/python-list/2007-February/427200.html for some similar issue. To monkey patch around this in local/lib/python2.5/commands.py change
{{{
def getstatusoutput(cmd):
    """Return (status, output) of executing cmd in a shell."""
    import os
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
    text = pipe.read()
    sts = pipe.close()
    if sts is None: sts = 0
    if text[-1:] == '\n': text = text[:-1]
    return sts, text
}}}
to
{{{
def getstatusoutput(cmd):
    """Return (status, output) of executing cmd in a shell."""
    import os
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
    text = "" # pipe.read()
    sts = "" # pipe.close()
    if sts is None: sts = 0
    if text[-1:] == '\n': text = text[:-1]
    return sts, text
}}}

With the above change the IPython import throws an excpetion, but Sage works. The fix is obviously to do something clean in IPython related to the readline import.
The above problem is caused by the IPython import. The problem goes away if we disable the following libedit import test in rlineimpl.py
{{{
uses_libedit = False
if sys.platform == 'darwin' and have_readline:
    import commands
    (status, result) = commands.getstatusoutput( "otool -L %s | grep libedit" % _rl.__file__ )
    if status == 0 and len(result) > 0:
        # we are bound to libedit - new in Leopard
        _rl.parse_and_bind("bind ^I rl_complete")
        print "Leopard libedit detected."
        uses_libedit = True
}}}
I will open a ticket for this problem shortly. The issue has been reported to the ipython-dev list.

Sage 64 bit OSX 10.5 build notes for Sage 3.2.3

Notes

fortran.spkg

Use OSX-gfortran.spkg (coming soon) which is a repackaged Gfortran 4.2.3 by the R people. It is quad universal.

Make local/bin/sage_fortran like

gfortran -m64 "$@"

Make sure to chmod 755 and extend DYLD_LIBRARY_PATH to include the Fortran runtime - maybe in toolchain?

gmp

use eMPIRe

Python

The notebook doesn't work unless ctypes are manually build. This is a bug in Python 2.5.2.

  • Python 2.6.1 ships with 64 Darwin support, but it is unclear if that is a drop in replacement for Python 2.5.x
  • Python 2.5.4 does not fix the issue in 2.5.2

The binary _ctypes.so extension was build manually using an older libffi release. See http://sourceware.org/libffi/ - note that the latest release at this point is libffi-3.0.8, released on December 19, 2008.

The issue might be fixable by using an external libffi.

atlas

The following error pops up, but it is harmless:

/bin/sh: /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/bin/which_fortran: No such file or directory

It should still be fixed.

pynac

No OSX64 bit support yet - an unclean version that builds would be:

diff -r 56d7250fb1dc spkg-install
--- a/spkg-install      Wed Oct 15 10:32:53 2008 +0200
+++ b/spkg-install      Tue Jan 06 13:40:13 2009 -0800
@@ -22,8 +22,10 @@
 build_pynac()
 {
     cd ${PYNACDIR}
-    CPPFLAGS=-I"$SAGE_LOCAL"/include/python2.5 PKG_CONFIG_PATH=${SAGE_LOCAL}/lib/pkgconfig ./configure --disable-static --prefix=${SAGE_LOCAL}
-    CPPFLAGS=-I"$SAGE_LOCAL"/include/python2.5 $MAKE
+    LDFLAGS="-m64"; export LDFLAGS [needs to be 64 bit OSX specific] 
+    PKG_CONFIG_PATH="$SAGE_LOCAL"/lib/pkgconfig/: export PKG_CONFIG_PATH
+    CPPFLAGS="-m64 -I\"$SAGE_LOCAL\"/include/python2.5" ./configure --disable-static --prefix=${SAGE_LOCAL}
+    CPPFLAGS="-m64 -I\"$SAGE_LOCAL\"/include/python2.5" $MAKE
     if [ $? -ne 0 ]; then
         echo "Error building pynac."
         exit 1

r

libpng trouble since the build with a dynamic libpng was fixed recently:

Error in dyn.load(file, ...) : 
  unable to load shared library '/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/spkg/build/r-2.6.1.p21/src/library/grDevices/libs/grDevices.so':
  dlopen(/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/spkg/build/r-2.6.1.p21/src/library/grDevices/libs/grDevices.so, 6): Symbol not found: __cg_png_create_info_struct
  Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib//libPng.dylib
Calls: <Anonymous> ... namespaceImport -> loadNamespace -> library.dynam -> dyn.load
Execution halted

The fix here is to analog to 32 bits to disable aqua support for now.

sagelib

sage -b: devel/sage/c_lib/SConstruct

## We want the debug and optimization flags, since debug symbols are so useful, etc.
env.Append( CFLAGS="-O2 -g -m64" )
env.Append( CXXFLAGS="-O2 -g -m64" )
env.Append( LINKFLAGS="-m64 -single_module -flat_namespace -undefined dynamic_lookup" )

The above fix needs to be dependent on SAGE64 being set. With the above flags set libcsage.dylib is build as a 64 bit library. The spkg-install does the linking, so everything should work on OSX 64 bit once a clean version of the above proto-patch is merged.

Another problem is that the memory.pyx extension needs to be linked against libcsage:

--- a/module_list.py    Mon Jan 05 23:03:45 2009 -0800
+++ b/module_list.py    Tue Jan 06 17:13:03 2009 -0800
@@ -854,7 +854,7 @@
 
     Extension('sage.rings.memory',
               sources = ['sage/rings/memory.pyx'],
-              libraries=['gmp','stdc++']),
+              libraries=['csage','ntl','gmp','stdc++']),
 
     Extension('sage.rings.morphism',
               sources = ['sage/rings/morphism.pyx']),

Otherwise Sage starts up, but doctesting fails always with

sage -t  "devel/sage/sage/rings/complex_interval_field.py"  
Traceback (most recent call last):
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/tmp/complex_interval_field.py", line 2, in <module>
    from sage.all_cmdline import *; 
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/all_cmdline.py", line 14, in <module>
    from sage.all import *
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/all.py", line 56, in <module>
    from sage.rings.memory import pmem_malloc
ImportError: dlopen(/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/rings/memory.so, 2): Symbol not found: _rand_n
  Referenced from: /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/rings/memory.so
  Expected in: dynamic lookup

Similar linker fixes are needed for Cygwin

ghmm

ghmm is build 32 bits only

libghmm.1.0.0.dylib:            Mach-O dynamically linked shared library i386
libghmm.1.dylib:                Mach-O dynamically linked shared library i386
libghmm.dylib:                  Mach-O dynamically linked shared library i386

Quick and ugly hack, needs SAGE64 specific cleanup:

Sprocketer:ghmm-20080813 michaelabshoff$ hg diff
diff -r 9d3e399ae771 spkg-install
--- a/spkg-install      Sun Aug 03 18:34:26 2008 -0700
+++ b/spkg-install      Tue Jan 06 15:31:08 2009 -0800
@@ -7,6 +7,9 @@
 # this does *NOT* work.  First the configure.in script is hardcoded to
 # ignore that option.  Second, if you change that then it turns out
 # that ghmm doesn't even compile.
+
+export CFLAGS="-O2 -g -m64"
+export LDFLAGS="-m64"
 
 ./configure --prefix="$SAGE_LOCAL" 

boehmgc

Also is build as 32 bit lib at the moment. Should be trivial to fix via something along the lines of

+export CFLAGS="-O2 -g -m64"
+export LDFLAGS="-m64"

in spkg-install.

singular

We need to enable system malloc for MacIntel since it is only chosen pre default for MacPPC. The ugly hack below needs to be cleaned up:

diff -r 0e3b296b487a spkg-install
--- a/spkg-install      Sun Nov 30 23:10:51 2008 -0800
+++ b/spkg-install      Tue Jan 06 16:46:38 2009 -0800
@@ -116,7 +116,8 @@
                 --enable-IntegerProgramming \
                 --disable-doc  \
                 "$DYNAMIC_KERNEL" \
-               "$ENABLE_DEBUG"
+               "$ENABLE_DEBUG" \
+               --with-malloc=system
 
     if [ $? -ne 0 ]; then
         echo "Unable to configure Singular."

But at exit we are having problems with double frees:

Sprocketer:sage-3.2.3-64bit michaelabshoff$ ./sage
----------------------------------------------------------------------
| Sage Version 3.2.3, Release Date: 2009-01-05                       |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: import sys
sage: sys.maxint
9223372036854775807
sage: !uname
Darwin
sage: 
Exiting SAGE (CPU time 0m0.07s, Wall time 0m13.65s).
sage.bin(162) malloc: *** error for object 0x106592030: Non-aligned pointer being freed (2)
*** set a breakpoint in malloc_error_break to debug
sage.bin(162) malloc: *** error for object 0x106592038: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
sage.bin(162) malloc: *** error for object 0x106591048: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
sage.bin(162) malloc: *** error for object 0x106591030: Non-aligned pointer being freed (2)
*** set a breakpoint in malloc_error_break to debug
Sprocketer:sage-3.2.3-64bit michaelabshoff$ ./sage

These also happen on Cygwin, so this needs to be investigated and fixed.

The problem is also reproducible on 32 bit OSX when compiling Singular to use the system's malloc:

Sprocketer:sage-3.2.3.alpha0 michaelabshoff$ ./sage 
----------------------------------------------------------------------
| Sage Version 3.2.3.alpha0, Release Date: 2008-12-24                |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: 
Exiting SAGE (CPU time 0m0.07s, Wall time 0m16.28s).
sage.bin(90498) malloc: *** error for object 0x5335018: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
sage.bin(90498) malloc: *** error for object 0x5335020: Non-aligned pointer being freed (2)
*** set a breakpoint in malloc_error_break to debug
sage.bin(90498) malloc: *** error for object 0x5333078: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
sage.bin(90498) malloc: *** error for object 0x5333068: Non-aligned pointer being freed
*** set a breakpoint in malloc_error_break to debug
Sprocketer:sage-3.2.3.alpha0 michaelabshoff$ 

The problem might be a similar issue as the scope problem found in Cython 0.11-devel in mid January. Note that the majority of the doctests below fail because minpoly() in libSingular segfaults in conditions where it should not be called in the first place.

tachyon

Fails due to 64 bit build problems - known problem with ticket

flintqs

Fails due to 64 bit build problems - known problem with ticket

cvxopt

Linker trouble - no clue why yet.

gcc -m64 -L/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib -bundle 
-undefined dynamic_lookup build/temp.macosx-10.3-i386-2.5/C/base.o build/temp.macosx-10.3-i386-2.5/C/dense.o 
build/temp.macosx-10.3-i386-2.5/C/sparse.o -L/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib -lm -llapack 
-lblas -lgfortran -o build/lib.macosx-10.3-i386-2.5/cvxopt/base.so
ld: library not found for -lgfortran
collect2: ld returned 1 exit status

The build issue goes away when installing gfortran directly into $SAGE_LOCAL, but it might also be a failure due to missing gfortran due to env issues. This needs to be verified.

scipy

Import issue with d1mach: Note that d1mach.o manages to be 32 bits:

Sprocketer:scipy-20071020-0.6.p4 michaelabshoff$ file ./src/build/temp.macosx-10.3-i386-2.5/scipy/integrate/mach/d1mach.o
./src/build/temp.macosx-10.3-i386-2.5/scipy/integrate/mach/d1mach.o: Mach-O object i386

This causes import failures all over the place as Scipy's special functions module does fail to import. This seems to be due to scipy using gfortran in some cases when it finds it instead of sage_fortran:

Found executable /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/bin/gfortran
Found executable /usr/bin/ld
Found executable /usr/bin/ar
Found executable /usr/bin/ranlib
compiling Fortran sources
Fortran f77 compiler: /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/bin/gfortran -Wall -ffixed-form -fno-s
econd-underscore -fPIC
Fortran f90 compiler: /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/bin/gfortran -Wall -fno-second-undersc
ore -fPIC
Fortran fix compiler: /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/bin/gfortran -Wall -ffixed-form -fno-s
econd-underscore -Wall -fno-second-underscore -fPIC
creating build/temp.macosx-10.3-i386-2.5/scipy/integrate/mach
compile options: '-c'
gfortran:f77: scipy/integrate/mach/d1mach.f
gfortran:f77: scipy/integrate/mach/i1mach.f
gfortran:f77: scipy/integrate/mach/r1mach.f
gfortran:f77: scipy/integrate/mach/xerror.f

One workaround is to use a dummy gfortran wrapper.

sympow

For now sympow is build in 32 bit mode, but it works:

Sprocketer:sage-3.2.3-64bit michaelabshoff$ file local/lib/sympow/sympow 
local/lib/sympow/sympow: Mach-O executable i386

Since OSX will always have a 32 bit runtime this is something we should be able to live with.

Doctest Failures

Currently 22 doctest failures:

        sage -t  "devel/sage/sage/calculus/calculus.py"
        sage -t  "devel/sage/sage/calculus/wester.py"
        sage -t  "devel/sage/sage/crypto/mq/sr.py"
        sage -t  "devel/sage/sage/groups/generic.py"
        sage -t  "devel/sage/sage/interfaces/lisp.py"
        sage -t  "devel/sage/sage/interfaces/qsieve.py"
        sage -t  "devel/sage/sage/libs/pari/gen.pyx"
        sage -t  "devel/sage/sage/rings/polynomial/laurent_polynomial.pyx"
        sage -t  "devel/sage/sage/rings/polynomial/multi_polynomial.pyx"
        sage -t  "devel/sage/sage/rings/polynomial/multi_polynomial_element.py"
        sage -t  "devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py"
        sage -t  "devel/sage/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pyx"
        sage -t  "devel/sage/sage/rings/polynomial/multi_polynomial_libsingular.pyx"
        sage -t  "devel/sage/sage/rings/polynomial/toy_buchberger.py"
        sage -t  "devel/sage/sage/schemes/elliptic_curves/ell_finite_field.py"
        sage -t  "devel/sage/sage/schemes/elliptic_curves/ell_generic.py"
        sage -t  "devel/sage/sage/schemes/elliptic_curves/ell_number_field.py"
        sage -t  "devel/sage/sage/schemes/elliptic_curves/ell_point.py"
        sage -t  "devel/sage/sage/schemes/generic/affine_space.py"
        sage -t  "devel/sage/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py"
        sage -t  "devel/sage/sage/tests/book_stein_ent.py"

A lot of the above are segaults caused by the tentative Singular vs. Givaro collision.

pre-scipy fix and install of R

41 Doctest failures, but many are easily fiaxable:

        sage -t  devel/sage/sage/calculus/wester.py # 3 doctests failed
        sage -t  devel/sage/sage/calculus/calculus.py # 0 doctests failed
        sage -t  devel/sage/sage/crypto/mq/sr.py # Segfault
        sage -t  devel/sage/sage/finance/time_series.pyx # 5 doctests failed
        sage -t  devel/sage/sage/functions/special.py # 5 doctests failed
        sage -t  devel/sage/sage/functions/transcendental.py # 5 doctests failed
        sage -t  devel/sage/sage/groups/generic.py # Segfault
        sage -t  devel/sage/sage/interfaces/expect.py # 11 doctests failed
        sage -t  devel/sage/sage/interfaces/lisp.py # 4 doctests failed
        sage -t  devel/sage/sage/interfaces/qsieve.py # 7 doctests failed
        sage -t  devel/sage/sage/interfaces/r.py # 176 doctests failed
        sage -t  devel/sage/sage/libs/pari/gen.pyx # 2 doctests failed
        sage -t  devel/sage/sage/modular/congroup.py # 14 doctests failed
        sage -t  devel/sage/sage/modular/cusps.py # 1 doctests failed
        sage -t  devel/sage/sage/modular/modsym/ambient.py # 4 doctests failed
        sage -t  devel/sage/sage/modular/modsym/boundary.py # 2 doctests failed
        sage -t  devel/sage/sage/modules/vector_double_dense.pyx # 12 doctests failed
        sage -t  devel/sage/sage/modules/vector_real_double_dense.pyx # 1 doctests failed
        sage -t  devel/sage/sage/numerical/test.py # 5 doctests failed
        sage -t  devel/sage/sage/numerical/optimize.py # 4 doctests failed
        sage -t  devel/sage/sage/plot/plot3d/list_plot3d.py # 6 doctests failed
        sage -t  devel/sage/sage/rings/arith.py # 3 doctests failed
        sage -t  devel/sage/sage/rings/integer.pyx # 4 doctests failed
        sage -t  devel/sage/sage/rings/polynomial/laurent_polynomial.pyx # Segfault
        sage -t  devel/sage/sage/rings/polynomial/multi_polynomial.pyx # Segfault
        sage -t  devel/sage/sage/rings/polynomial/multi_polynomial_element.py # Segfault
        sage -t  devel/sage/sage/rings/polynomial/multi_polynomial_ideal_libsingular.pyx # Segfault
        sage -t  devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1 doctests failed
        sage -t  devel/sage/sage/rings/polynomial/multi_polynomial_libsingular.pyx # Segfault
        sage -t  devel/sage/sage/rings/polynomial/toy_buchberger.py # Segfault
        sage -t  devel/sage/sage/rings/polynomial/toy_d_basis.py # 2 doctests failed
        sage -t  devel/sage/sage/schemes/elliptic_curves/ell_generic.py # Segfault
        sage -t  devel/sage/sage/schemes/elliptic_curves/ell_finite_field.py # Segfault
        sage -t  devel/sage/sage/schemes/elliptic_curves/ell_number_field.py # Segfault
        sage -t  devel/sage/sage/schemes/elliptic_curves/ell_point.py # Segfault
        sage -t  devel/sage/sage/schemes/generic/affine_space.py # Segfault
        sage -t  devel/sage/sage/schemes/hyperelliptic_curves/hyperelliptic_finite_field.py # Segfault
        sage -t  devel/sage/sage/stats/r.py # 1 doctests failed
        sage -t  devel/sage/sage/stats/test.py # 1 doctests failed
        sage -t  devel/sage/sage/tests/book_stein_modform.py # 4 doctests failed
        sage -t  devel/sage/sage/tests/book_stein_ent.py # 3 doctests failed

Reasons for failures:

  • different gmp, i.e. eMPIRe, accounts for 10 failures
  • the missing compoenents also cause failures
  • Singular does double frees at exit on occasion due to the use of system malloc, a patch to work around those has been done

gdb problems

It seems that ipyhon is causing trouble when starting Sage in 64 bit mode on OSX under gdb:

(gdb) r
Starting program: /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/bin/python /Users/michaelabshoff/Desktop/sage-3.2.3-64bit/tmp/.doctest_ell_finite_field.py
warning: posix_spawn failed, trying execvp, error: 86
Traceback (most recent call last):
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/tmp/.doctest_ell_finite_field.py", line 2, in <module>
    from sage.all_cmdline import *; 
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/all_cmdline.py", line 14, in <module>
    from sage.all import *
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/all.py", line 64, in <module>
    from sage.misc.all       import *         # takes a while
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/misc/all.py", line 16, in <module>
    from sage_timeit_class import timeit
  File "sage_timeit_class.pyx", line 3, in sage.misc.sage_timeit_class (sage/misc/sage_timeit_class.c:603)
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/misc/sage_timeit.py", line 12, in <module>
    import timeit as timeit_, time, math, preparser, interpreter
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/sage/misc/interpreter.py", line 95, in <module>
    import IPython.ipapi
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/IPython/__init__.py", line 57, in <module>
    __import__(name,glob,loc,[])
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/IPython/ipstruct.py", line 22, in <module>
    from IPython.genutils import list2dict2
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/IPython/genutils.py", line 118, in <module>
    import IPython.rlineimpl as readline
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/site-packages/IPython/rlineimpl.py", line 37, in <module>
    (status, result) = commands.getstatusoutput( "otool -L %s | grep libedit" % _rl.__file__ )
  File "/Users/michaelabshoff/Desktop/sage-3.2.3-64bit/local/lib/python2.5/commands.py", line 54, in getstatusoutput
    text = pipe.read()
IOError: [Errno 4] Interrupted system call

Program exited with code 01.

The above problem is caused by the IPython import. The problem goes away if we disable the following libedit import test in rlineimpl.py

uses_libedit = False
if sys.platform == 'darwin' and have_readline:
    import commands
    (status, result) = commands.getstatusoutput( "otool -L %s | grep libedit" % _rl.__file__ )
    if status == 0 and len(result) > 0:
        # we are bound to libedit - new in Leopard
        _rl.parse_and_bind("bind ^I rl_complete")
        print "Leopard libedit detected."
        uses_libedit = True

I will open a ticket for this problem shortly. The issue has been reported to the ipython-dev list.