Differences between revisions 1 and 9 (spanning 8 versions)
Revision 1 as of 2010-07-02 21:18:38
Size: 28960
Editor: PeterJeremy
Comment: Initial commit, based on freebsd/sage-4.3
Revision 9 as of 2010-07-25 07:03:53
Size: 27933
Editor: PeterJeremy
Comment: numpy tweaks to make liblapack.so behave
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Sage FreeBSD 8.x build notes for Sage 4.4.4 = ## page was renamed from freebsd/sage-4.4.4
= Sage FreeBSD 8.x build notes for Sage 4.5 =
Line 5: Line 6:
In general, commented-out sections are direct copies of my previous porting efforts and may not be required for sage-4.4.4. They have been left in case they are found to be required during testing. In general, commented-out sections are direct copies of my previous porting efforts and may not be required for sage-4.5. They have been left in case they are found to be required during testing.
Line 16: Line 17:
 * Install ports/shells/bash or ports/shells/bash3 (I used 4.1.5)  * Install ports/shells/bash or ports/shells/bash3 (I used 4.1.7)
Line 29: Line 30:
FreeBSD 7.x hasn't been tested with Sage 4.4.4 but is expected to work.

 * Unpack sage-4.4.4.tar
 * `cd sage-4.4.4`
 * Unpack [[attachment:sage-4.4.4.patch]] which includes the following:
FreeBSD 7.x hasn't been tested with Sage 4.5 but is expected to work.

 * Unpack sage-4.5.tar
 * `cd sage-4.5`
 * Unpack [[attachment:sage-4.5.patch]] which includes the following:
Line 40: Line 41:
  . `SAGE_PORT=yes SAGE_FORTRAN=/usr/local/bin/gfortran45 SAGE_FORTRAN_LIB=/usr/local/lib/gcc45/libgfortran.so gmake`

Note that it's not currently possible to use gcc45/g++45 to build Sage - configuration errors in the FreeBSD port of gcc45 means that the wrong shared libraries get used if this is attempted. See http://www.freebsd.org/cgi/query-pr.cgi?pr=129518
  . `LD_LIBRARY_PATH=/usr/local/lib/gcc45 SAGE_PORT=yes SAGE_FORTRAN=/usr/local/bin/gfortran45 SAGE_FORTRAN_LIB=/usr/local/lib/gcc45/libgfortran.so gmake`

Note that the LD_LIBRARY_PATH is needed to work arounf configuration errors in the FreeBSD port of gcc45 - see http://www.freebsd.org/cgi/query-pr.cgi?pr=129518
Line 49: Line 50:
Currently, the following tests fail on FreeBSD 8.1-PRERELEASE/amd64. Full logs at [[attachment:sage-4.4.4.freebsd8.1-amd64.test.log]].
{{{

}}}
Currently, the following tests fail on FreeBSD 8.1-PRERELEASE/amd64.
{{{#!wiki comment
Full logs at [[attachment:sage-4.4.4.freebsd8.1-amd64.test.log]].
}}}
{{{
TBD
}}}
{{{#!wiki comment
Line 58: Line 63:

{{{#!wiki comment
Line 70: Line 73:
 * The patch to standard/deps ensures that bash is used. By default, gmake will use /bin/sh to execute commands and the patched line sources local/bin/sage-env - which includes the bash'ism 'source' instead of '.'. Whilst that file begins with a #! line invoking bash, because it must be sourced, it will actually execute in the invoking shell.
Line 73: Line 75:
Various fixes to make it compile on FreeBSD
 * FreeBSD uses an '_fbsd' suffix on the ELF format supported by `ld` - prevents `ld: unrecognised emulation mode: elf_x86_64` error during atlas build. Reported upstream as https://sourceforge.net/tracker/index.php?func=detail&aid=2728930&group_id=23725&atid=379482
{{{#!wiki comment
 * Treat shared libraries the same as Linux - otherwise they aren't correctly detected by (eg) numpy. (sage-specific)
Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/7827|#7827]]

 * `sysctl` is not in the default user path so use an explicit pathname (optional)
 * The newer AMD CPUs all identify as 'Athlon' so use the existence of multiple cores to distinguish between K7 (i386) and later (Hammer) CPUs. (optional)
 * Correct various sysctl OIDs to match the names FreeBSD uses. (optional) This and previous two reported upstream as https://sourceforge.net/tracker/?func=detail&atid=379483&aid=2728927&group_id=23725
 * Building the `libclapack.so` should result in a `libclapack.so` being created. This appears to be a copy-and-paste error in atlas and has been reported as https://sourceforge.net/tracker/?func=detail&atid=379483&aid=2728935&group_id=23725 (Note that this is not relevant to sage as libclapack is not built or used).
 * numpy on FreeBSD expects atlas to build different and (according to the FreeBSD numpy port, static) threaded libraries: libatlas_r instead of libatlas and libalapack_r instead of liblapack. libatlas_r is built as part of the threaded version of atlas. libalapack_r is a FreeBSD special which explicitly combines all of liblapack from the atlas lapack build with the threaded atlas version of liblapack.

numpy error from last point above:
{#{{
atlas_blas_info:
  libraries f77blas,cblas,atlas_r not found in /usr/home/peter/sage-4.1/local/lib
  NOT AVAILABLE

/usr/home/peter/sage-4.1/spkg/build/numpy-1.3.0.p0/src/numpy/distutils/system_info.py:1383: UserWarning:
    Atlas (http://math-atlas.sourceforge.net/) libraries not found.
    Directories to search for the libraries can be specified in the
    numpy/distutils/site.cfg file (section [atlas]) or by setting
    the ATLAS environment variable.
  warnings.warn(AtlasNotFoundError.__doc__)
...
atlas_info:
  libraries f77blas,cblas,atlas_r not found in /usr/home/peter/sage-4.1/local/lib
  libraries lapack_atlas not found in /usr/home/peter/sage-4.1/local/lib
numpy.distutils.system_info.atlas_info
  NOT AVAILABLE

/usr/home/peter/sage-4.1/spkg/build/numpy-1.3.0.p0/src/numpy/distutils/system_info.py:1290: UserWarning:
    Atlas (http://math-atlas.sourceforge.net/) libraries not found.
    Directories to search for the libraries can be specified in the
    numpy/distutils/site.cfg file (section [atlas]) or by setting
    the ATLAS environment variable.
  warnings.warn(AtlasNotFoundError.__doc__)
...
}}}
`liblapack.so` includes undefined references to `__powidf2` and `__powisf2`, which are defined in `libgcc` (no other Sage shared libraries appear to rely on `libgcc` helper functions. Unfortunately, for reasons I don't fully understand, linking `liblapack.so` against `libgcc.a` fails, even when building a normal executable. One example of the resultant error occurs when configuring numpy:
{{{
gcc _configtest.o -L/tank/obj/sage/sage-4.5/local/lib -llapack -lf77blas -lcblas -latlas -o _configtest
/usr/local/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/local/lib/gcc45/gcc/x86_64-portbld-freebsd8.1/4.5.1/libgcc.a(_powidf2.o) is referenced by DSO
/usr/local/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
/usr/local/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/local/lib/gcc45/gcc/x86_64-portbld-freebsd8.1/4.5.1/libgcc.a(_powidf2.o) is referenced by DSO
/usr/local/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
failure.
removing: _configtest.c _configtest.o
Status: 255
}}}

The fix is to add a dependency on `libgcc_s.so` when (re-)building `liblapack.so` in `make_correct_shared.sh`.

Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/?|#?]]

=== cephes-2.8 ===
 * FreeBSD does not yet include a full C99 libm so enable cephes on FreeBSD.
 * Correct error in the patched c9x-complex/makefile that refers to non-existent test sources.
 * Enable '-e' option on spkg-install to catch errors

The overall approach used on the FreeBSD is for cephes to create `complex.h`, `math.h` and `libm.so` which are installed under $SAGE_LOCAL and contain the missing C99 functions then fall back to the FreeBSD base versions for functions existing in FreeBSD.
This mean that references to `<math.h>`, `<complex.h>` or `-lm` will appear to reference a complete set of C99 functions, split over two physical locations.

Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/9543|#9543]]
Line 118: Line 109:
=== cvxopt-0.9.p8 ===
Needs patch to ensure that $SAGE_LOCAL/include is included in the search path to correctly pick up the C99 functions that do not exist in the FreeBSD base system (see comments on cephes).

Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/?|#?]]
Line 128: Line 123:
=== flintqs-20070817.p5 ===

`TonelliShanks.h` references `int32_t` but does not directly include `<stdint.h>`. On FreeBSD using gcc45 (but not the base gcc), this causes compilation to fail with:
{{{
g++ -ansi -c TonelliShanks.cpp -o TonelliShanks.o -I/tank/obj/sage/sage-4.5/local/include -Wall -Wno-sign-compare -fomit-frame-pointer -O2
In file included from TonelliShanks.cpp:31:0:
TonelliShanks.h:41:8: error: 'int32_t' does not name a type
TonelliShanks.h:43:51: error: 'int32_t' has not been declared
TonelliShanks.cpp:67:1: error: 'int32_t' does not name a type
TonelliShanks.cpp:136:54: error: 'int32_t' has not been declared
TonelliShanks.cpp: In function 'void sqrtmodpk(__mpz_struct*, __mpz_struct*, __mpz_struct*, __mpz_struct*, int)':
TonelliShanks.cpp:140:11: error: 'int32_t' was not declared in this scope
TonelliShanks.cpp:140:19: error: expected ';' before 'i'
TonelliShanks.cpp:140:25: error: 'i' was not declared in this scope
make[2]: *** [TonelliShanks.o] Error 1
make[2]: Leaving directory `/tank/obj/sage/sage-4.5/spkg/build/flintqs-20070817.p5/src'
Error building William Hart's Quadratic Sieve
}}}

As a work-around, make `TonelliShanks.h` idempotent on FreeBSD (it probably should be on all architectures but making the patch FreeBSD-specific simplifies testing).

Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/9545|#9545]]
Line 218: Line 236:
=== matplotlib-0.99.1.p4 === === matplotlib-0.99.3 ===
Line 241: Line 259:
gcc4.5 (though not gcc4.2) appears to define putchar() in a way that breaks the putchar() definitions inside ttconv. I couldn't quickly identify what the underlying cause was so I took the easy way out and undef'd the offending putchar() macro. gcc4.3 (though not gcc4.2 or gcc4.5) appears to define putchar() in a way that breaks the putchar() definitions inside ttconv. I couldn't quickly identify what the underlying cause was so I took the easy way out and undef'd the offending putchar() macro.
Line 245: Line 263:
Reported upstream as https://sourceforge.net/tracker/?func=detail&aid=3031051&group_id=80706&atid=560722
Line 274: Line 293:
 * `$SAGE_LOCAL/include` needs to be added to the search path to pick up the correct `<math.h>` (see cephes).
Line 278: Line 298:
FreeBSD refers to the x86_64 architecture under its original name of 'amd64' so use this as an alias for x86_64. The `-fPIC' fix is needed to correct:
{{{
gcc -o libpari-gmp.so.2.3.3 -shared -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -Wl,-shared,-soname=libpari-gmp.so.2 mp.o mpinl.o Flx.o Qfb.o RgX.o alglin1.o alglin2.o arith1.o arith2.o base1.o base2.o base3.o base4.o base5.o bibli1.o bibli2.o buch1.o buch2.o buch3.o buch4.o galconj.o gen1.o gen2.o gen3.o ifactor1.o perm.o polarit1.o polarit2.o polarit3.o rootpol.o subcyclo.o subgroup.o trans1.o trans2.o trans3.o anal.o compat.o default.o errmsg.o es.o init.o intnum.o members.o sumiter.o aprcl.o elldata.o elliptic.o galois.o groupid.o kummer.o mpqs.o nffactor.o part.o stark.o subfield.o thue.o -lc -lm -L/home/peter/sage/sage-4.4.4/local/lib -lgmp
/usr/bin/ld: mp.o: relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC
mp.o: could not read symbols: Bad value
*** Error code 1

Stop in /home/peter/sage/sage-4.4.4/spkg/build/pari-2.3.3.p5/src/Ofreebsd-amd64.
}}}

Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/7825|#7825]]
Reported upstream as http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1022
The `Configure` script does not detect `log2`, which it should. (This appears to be an intrinsic bug because it doesn't detect either `exp2` or `log2` on Linux). The top line of spkg-install is also corrupt.

These are left for now because [[http://trac.sagemath.org/sage_trac/ticket/9343|#9343]] includes a new pari - which I have not checked yet.
Line 320: Line 331:
=== readline-6.0.p1 ===

readline-6.0.p1/spkg-install contains a typo in some FreeBSD-specific code, leading to the following error:

{{{
...
/bin/sh ../support/shlib-install -O freebsd8.0 -d /home/peter/sage/sage-4.4.4/local/lib -b /home/peter/sage/sage-4.4.4/local/bin -i "/usr/bin/install -c -m 644" libreadline.so.6.0
install: you may need to run ldconfig
make[1]: Leaving directory `/home/peter/sage/sage-4.4.4/spkg/build/readline-6.0.p1/src/shlib'
ln: SAGE_LOCAL/lib/libreadline.so: No such file or directory
}}}

The affected code is no longer required with readline-6.0 so delete it.

FreeBSD 3.x and later default to ELF, rather then a.out. A utility objformat(1) was temporarily introduced to enable third-party applications to determine te object format. This has now been deleted and code should assume ELF format if it does not exist. Explicitly linking libreadline against libtermcap is necessary to ensure that dependencies are picked up.

Trac ticket [[http://trac.sagemath.org/sage_trac/ticket/7821|#7821]]

=== sage-4.4.4 ===
 * Compiling `sage/combinat/partitions_c.cc` fails because FreeBSD 7.x does not define `sqrtl` (it was introduced in FreeBSD 8.0). As a hackish workaround, define sqrtl to be sqrt on older versions of FreeBSD.
 * FreeBSD does not include a definition for log2() in libm. Use a simplistic definition of log2(x) = log2(e) * ln(x) - this is numerically poor but can be cleaned up later if required.

=== sage-4.5 ===
 * Compiling `sage/combinat/partitions_c.cc` fails because FreeBSD 7.x does not define `sqrtl` (it was introduced in FreeBSD 8.0). As a hackish workaround, define sqrtl to be sqrt on older versions of FreeBSD. This will be removed once the cephes integration is complete.
 * FreeBSD does not include a definition for log2() in libm. Use a simplistic definition of log2(x) = log2(e) * ln(x) - this is numerically poor but can be cleaned up later if required. This will be removed once the cephes integration is complete.
Line 344: Line 338:
 * `sage/symbolic/pynac.cpp` fails to compile because FreeBSD libm is mostly missing long double functions - specifically tgammal() and lgammal() in this case.

Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/?|#?]]
=== sage_scripts-4.4.4 ===
 * `sage/symbolic/pynac.cpp` fails to compile because FreeBSD libm is mostly missing long double functions - specifically tgammal() and lgammal() in this case. This is being resolved by integrating cephes into the FreeBSD build of sage.

Trac ticket: [[http://trac.sagemath.org/sage_trac/ticket/?|#?]]

=== sage_scripts-4.5 ===
Line 396: Line 391:
=== singular-3.1.0.4.p6 === === singular-3.1.0.4.p7 ===

Sage FreeBSD 8.x build notes for Sage 4.5

Note that this is a work-in-progress and not currently complete

Contents

Overall build environment differences

  • sh and /bin/sh are a POSIX shell, rather than bash.

  • make is the BSD make, not GNU make

Preparatory work

  • Install ports/shells/bash or ports/shells/bash3 (I used 4.1.7)
  • Install ports/devel/gmake
  • Install ports/lang/gcc45 - FreeBSD no longer ships with a Fortran compiler by default.
  • Install ports/devel/autoconf262
  • Install ports/converters/libiconv
  • Ensure POSIX semaphores are available. This is required for ecl (at least). These are not available by default before FreeBSD 7.3 or 8.0 and should be enabled by either kldload sem or building a kernel with options P1003_1B_SEMAPHORES. If they are not available, building ecl will fail with Bad system call.

It's possible there are other dependencies, I haven't tried building sage in a clean (tinderbox) environment.

Building Sage

On FreeBSD 8.x

FreeBSD 7.x hasn't been tested with Sage 4.5 but is expected to work.

  • Unpack sage-4.5.tar
  • cd sage-4.5

  • Unpack sage-4.5.patch which includes the following:

    • Create symlinks to mask name differences.
    • ln -s /usr/local/bin/gmake local/bin/make

    • ln -s /usr/local/bin/bash local/bin/sh

    • ln -s /usr/local/bin/gfortran45 local/bin/gfortran

    • Various patches as described below into spkg/patches

  • Build Sage
    • LD_LIBRARY_PATH=/usr/local/lib/gcc45 SAGE_PORT=yes SAGE_FORTRAN=/usr/local/bin/gfortran45 SAGE_FORTRAN_LIB=/usr/local/lib/gcc45/libgfortran.so gmake

Note that the LD_LIBRARY_PATH is needed to work arounf configuration errors in the FreeBSD port of gcc45 - see http://www.freebsd.org/cgi/query-pr.cgi?pr=129518

The gmake to make symlink is necessary to compile (eg) eclib - which is documented as requiring GNU make, and has this symlink as a suggested workaround.

Current Status

Currently, the following tests fail on FreeBSD 8.1-PRERELEASE/amd64.

TBD

Notes on spkgs and attached patches

base.patch

  • The patch to base/sage-spkg enables the local patching that the rest of the patches rely on. Note that this patch is not intended to be merged into sage but provides a convenient mechanism to apply local patches without requiring that the spkg files are locally re-rolled.

atlas-3.8.3.p12

liblapack.so includes undefined references to __powidf2 and __powisf2, which are defined in libgcc (no other Sage shared libraries appear to rely on libgcc helper functions. Unfortunately, for reasons I don't fully understand, linking liblapack.so against libgcc.a fails, even when building a normal executable. One example of the resultant error occurs when configuring numpy:

gcc _configtest.o -L/tank/obj/sage/sage-4.5/local/lib -llapack -lf77blas -lcblas -latlas -o _configtest
/usr/local/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/local/lib/gcc45/gcc/x86_64-portbld-freebsd8.1/4.5.1/libgcc.a(_powidf2.o) is referenced by DSO
/usr/local/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
/usr/local/bin/ld: _configtest: hidden symbol `__powidf2' in /usr/local/lib/gcc45/gcc/x86_64-portbld-freebsd8.1/4.5.1/libgcc.a(_powidf2.o) is referenced by DSO
/usr/local/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
failure.
removing: _configtest.c _configtest.o
Status: 255

The fix is to add a dependency on libgcc_s.so when (re-)building liblapack.so in make_correct_shared.sh.

Trac ticket: #?

cephes-2.8

  • FreeBSD does not yet include a full C99 libm so enable cephes on FreeBSD.
  • Correct error in the patched c9x-complex/makefile that refers to non-existent test sources.
  • Enable '-e' option on spkg-install to catch errors

The overall approach used on the FreeBSD is for cephes to create complex.h, math.h and libm.so which are installed under $SAGE_LOCAL and contain the missing C99 functions then fall back to the FreeBSD base versions for functions existing in FreeBSD. This mean that references to <math.h>, <complex.h> or -lm will appear to reference a complete set of C99 functions, split over two physical locations.

Trac ticket: #9543

cvxopt-0.9.p8

Needs patch to ensure that $SAGE_LOCAL/include is included in the search path to correctly pick up the C99 functions that do not exist in the FreeBSD base system (see comments on cephes).

Trac ticket: #?

flintqs-20070817.p5

TonelliShanks.h references int32_t but does not directly include <stdint.h>. On FreeBSD using gcc45 (but not the base gcc), this causes compilation to fail with:

g++ -ansi -c TonelliShanks.cpp -o TonelliShanks.o -I/tank/obj/sage/sage-4.5/local/include -Wall -Wno-sign-compare -fomit-frame-pointer -O2
In file included from TonelliShanks.cpp:31:0:
TonelliShanks.h:41:8: error: 'int32_t' does not name a type
TonelliShanks.h:43:51: error: 'int32_t' has not been declared
TonelliShanks.cpp:67:1: error: 'int32_t' does not name a type
TonelliShanks.cpp:136:54: error: 'int32_t' has not been declared
TonelliShanks.cpp: In function 'void sqrtmodpk(__mpz_struct*, __mpz_struct*, __mpz_struct*, __mpz_struct*, int)':
TonelliShanks.cpp:140:11: error: 'int32_t' was not declared in this scope
TonelliShanks.cpp:140:19: error: expected ';' before 'i'
TonelliShanks.cpp:140:25: error: 'i' was not declared in this scope
make[2]: *** [TonelliShanks.o] Error 1
make[2]: Leaving directory `/tank/obj/sage/sage-4.5/spkg/build/flintqs-20070817.p5/src'
Error building William Hart's Quadratic Sieve

As a work-around, make TonelliShanks.h idempotent on FreeBSD (it probably should be on all architectures but making the patch FreeBSD-specific simplifies testing).

Trac ticket: #9545

matplotlib-0.99.3

Add support for FreeBSD later than 6.x. Otherwise you get :

BUILDING MATPLOTLIB
            matplotlib: 0.99.1
                python: 2.6.2 (r262:71600, Jan  3 2010, 12:58:40)  [GCC
                        4.2.1 20070719  [FreeBSD]]
              platform: freebsd8

REQUIRED DEPENDENCIES
Traceback (most recent call last):
  File "setup.py", line 123, in <module>
    if not check_for_numpy():
  File "/home/peter/sage/sage-4.4.4/spkg/build/matplotlib-0.99.1.p2/src/setupext.py", line 506, in check_for_numpy
    add_base_flags(module)
  File "/home/peter/sage/sage-4.4.4/spkg/build/matplotlib-0.99.1.p2/src/setupext.py", line 327, in add_base_flags
    [os.path.join(p, 'include') for p in basedir[sys.platform] ])
KeyError: 'freebsd8'

Trac #5873 Reported upstream as https://sourceforge.net/tracker/?func=detail&aid=3031051&group_id=80706&atid=560722

numpy-1.3.0.p3

  • __init__.py needs a sage-specific patch to prefer sage_fortran on FreeBSD. This is necessary to prevent matplotlib dying with:

BUILDING MATPLOTLIB
            matplotlib: 0.99.1
                python: 2.6.2 (r262:71600, Jan  3 2010, 12:58:40)  [GCC
                        4.2.1 20070719  [FreeBSD]]
              platform: freebsd8

REQUIRED DEPENDENCIES
                 numpy: no
                        * You must install numpy 1.1 or later to build
                        * matplotlib.
  • By default, numpy references threaded atlas libraries, as well as a custom variant on the lapack library, on FreeBSD. The reasoning behind this is unclear - there is nothing in the numpy documentation to indicate whether a threaded or non-threaded atlas is needed and the publicly available SVN logs do not mention this code. A query to the numpy mailing list elicited a response that either threaded or non-threaded atlas can be used and suggesting that the special-casing for FreeBSD may be obsolete. By default, atlas is built non-threaded and r-2.6.1.p23 assumes a non-threaded atlas and fails when only the threaded libraries are installed. Based on this, the special casing for FreeBSD was removed from numpy - it now uses the same libraries irrespective of the host OS.

  • $SAGE_LOCAL/include needs to be added to the search path to pick up the correct <math.h> (see cephes).

Trac ticket: #7831

pari-2.3.5.p1

The Configure script does not detect log2, which it should. (This appears to be an intrinsic bug because it doesn't detect either exp2 or log2 on Linux). The top line of spkg-install is also corrupt.

These are left for now because #9343 includes a new pari - which I have not checked yet.

sage-4.5

  • Compiling sage/combinat/partitions_c.cc fails because FreeBSD 7.x does not define sqrtl (it was introduced in FreeBSD 8.0). As a hackish workaround, define sqrtl to be sqrt on older versions of FreeBSD. This will be removed once the cephes integration is complete.

  • FreeBSD does not include a definition for log2() in libm. Use a simplistic definition of log2(x) = log2(e) * ln(x) - this is numerically poor but can be cleaned up later if required. This will be removed once the cephes integration is complete.
  • sage/groups/perm_gps/permgroup_element.c fails to compile because LONG_LONG_MAX is not available on FreeBSD. Some googling suggests that this macro is either a GNU extension or is deprecated in C99 and has been replaced by LLONG_MAX - I have not been able to find a direct reference but indirect references include the following links: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=168346#19 http://linux.softpedia.com/progChangelog/GNU-ddrescue-Changelog-6106.html http://clang.llvm.org/doxygen/limits_8h-source.html

Remaining issues include:

  • sage/symbolic/pynac.cpp fails to compile because FreeBSD libm is mostly missing long double functions - specifically tgammal() and lgammal() in this case. This is being resolved by integrating cephes into the FreeBSD build of sage.

Trac ticket: #?

sage_scripts-4.5

Patch sage-spkg to apply local patches. This patch also disables deletion of the spkg/build/FOO temporary directories - which was useful during porting. This latter patch can be safely removed.

singular-3.1.0.4.p7

By default, you get the following, which is corrected by the patch to singuname.sh:

make[2]: Entering directory `/home/peter/sage/sage-4.4.4/spkg/build/singular-3-1-0-4-20090818.p2/src'
make[2]: *** No rule to make target `distclean'.  Stop.
make[2]: Leaving directory `/home/peter/sage/sage-4.4.4/spkg/build/singular-3-1-0-4-20090818.p2/src'
rm: /home/peter/sage/sage-4.4.4/local/bin/Singular*: No such file or directory
creating cache ./config.cache
checking uname for singular... unknown
configure: error: Unknown architecture: Check singuname.sh
Unable to configure Singular.

Correct configure script for amd64 by patching the autoconf inputs and re-running autoconf. This corrects a problem where linking libsingular.so reports lots of undefined references to both internal om* functions and functions within libncurses.

Several other trivial fixes to support dynamic linking on FreeBSD/amd64.

Trac ticket: #7832