[SciPy-User] Notes on building scipy on Solaris 10 with SunStudio.

[Bryan Hodgson]

Folks,

This is not a problem report, it's a (mostly) success report.  I'm
a sysadmin, and not a python-ist or an scipy end-user.

I found the process of getting a working scipy build on Solaris 10
to be rather too opaque (even with assistance from Google), and
decided to post my results in the hope that they might help others.
The list seems about as good a spot as any.

Building 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:

The build environment is:

site.cfg (for both numpy and scipy) says:

  [DEFAULT]
  library_dirs = /opt/sunstudio12.1/lib
  [blas_opt]
  libraries = sunperf
  [lapack_opt]
  libraries = sunmath

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.

numpy 1.4.1 builds with the usual warnings about mis-matched
pointer declarations from system headers and code not reached.

'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 1
  
This 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.

Hope this helps someone ...

Bryan