These instructions describe the experience of one user, posted to the mailing list on 24 Aug 2010, on how to build numpy 1.4.1 and scipy 0.8.0 on Solaris 10 x86 and sparc, update 7 and 5 respectively. Same results on x86 update 8 with current recommended patches.
All machines built with SUNWCprog metacluster (e.g. the Solaris developer environment), and Sun Studio 12 update 1 (unpatched original release) at /opt/sunstudio12.1 (the default location for this release). The default system /usr/bin/python (from Sun) is 2.4.4. I'm willing to avoid building BLAS / LAPACK if I can avoid doing that, and the sunmath / sunperf libs bundled with Sun Studio work. Details:
Build environment
site.cfg (for both numpy and scipy) says:
[DEFAULT] library_dirs = /opt/sunstudio12.1/lib [blas_opt] libraries = sunperf [lapack_opt] libraries = sunmath
Shell environment
The relevant fraction of the shell environment for both is:
PATH=/opt/sunstudio12.1/bin:/usr/ccs/bin:/usr/bin:/usr/sfw/bin:/usr/sbin; export PATH ATLAS=None; export ATLAS BLAS=/opt/sunstudio12.1/lib/libsunperf.so; export BLAS LAPACK=/opt/sunstudio12.1/lib/libsunmath.so; export LAPACK
pyCC finds the compilers by their inclusion in PATH. SunStudio was installed with '--create-symlinks', creating links in /usr/bin; that may have helped.
CC,CXX,CFLAGS and friends are not set.
For scipy, LDFLAGS='-lCrun' was added to the environment to get resolve run-time linker errors produced scipy.test() (discussed below).
crle is set to installation default, no modifications present. LD_LIBRARY_PATH is unset for the build.
Building
numpy 1.4.1 builds with the usual warnings about mismatched pointer declarations from system headers and code not reached.
Running the tests with python -c "import numpy;numpy.test()" fails with a complaint that the default nose is too old. nose 0.11.x does not work, nose 0.10.(3,4) worked, no errors from numpy.test(). (All modules were packaged to permit clean re-installation, and as a final step all was built / installed on a machine that had not yet seen scipy.)
Building scipy 0.8.0 out of the box ends with:
scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/zneupd.f:
zneupd:
f90: Internal Error, code=fw-interface-cexp-277, last src=scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/zneupd.f:673
f90: Warning: The option -xcode=pic32 has no effect on x86
scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/zneupd.f:
zneupd:
f90: Internal Error, code=fw-interface-cexp-277, last src=scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/zneupd.f:673
error: Command "/opt/sunstudio12.1/bin/f90 -ftrap=%none -f77 -xcode=pic32 -Iscipy/sparse/linalg/eigen/arpack/ARPACK/SRC -I/usr/lib/python2.4/site-packages/numpy/core/include -c -c scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/zneupd.f -o build/temp.solaris-2.10-i86pc-2.4/scipy/sparse/linalg/eigen/arpack/ARPACK/SRC/zneupd.o" failed with exit status 1This is a SunStudio problem fixed by installing patches:
sparc: 128231-05 128232-03 141854-01 141860-03
i386: 141852-06 141853-03 141855-01 141858-06
There is a gcc compiler directive (-Wall) in scipy/ndimage/setup.py that must be removed for the compiler to succeed.
Without LDFLAGS=lCrun, scipy.test() records 6 errors against scipy/sparse/sparsetools/_csr.so:
ImportError: ld.so.1: python2.4: fatal: relocation error: file /usr/lib/python2.4/site-packages/scipy/sparse/sparsetools/_csr.so: symbol __1c2k6Fpv0_v_: referenced symbol not found
The missing mangled C++ symbol is in /usr/lib/libCrun.so.1. It's not clear to me why the linker didn't pick it up, but moving on ...
There are 3 python assertion failures (not detailed here).
Building scipy with LDFLAGS=-lCrun results in an abend of scipy.test() evidently originating in scipy/io/tests/test_netcdf.py (line 104) at test_read_write_sio. After running our scipy code against the resulting scipy, we concluded that this was either an isolated error or a problem on the test suite in our environment.
All done.