I want to install a certain (non-public, numerical) python module on a remote (Debian squeeze) system on which I do not have root (or sudo) privileges. As the python-dev package was not installed, I compiled and locally installed python 2.7 (using ./configure --prefix=$HOME/rt). I similarly installed numpy, scipy and tinyarray by using the --user option of setup.py, as these are required. Afterwards, I installed the module, which did not present any problems. However, upon importing the module in python, I get the following message:
RuntimeWarning: The installed SciPy does not use UMFPACK. Instead, SciPy will use the version of SuperLu it is shipped with. Performance can be very poor in this case.
Indeed the performance turned out to be poor. Upon some further research it turned out that the module supports use of both umfpack and MUMPS. Both would be acceptable, but on different system, I found MUMPS to have slightly better performance. I have had no success with installing either. Regarding umfpack, I did not find any information on how to install it other than a scipack for scipy which does not seem to exist anymore.
So I attempted to install MUMPS.
from the INSTALL file of the module:
The setup script has to know how to link against LAPACK & BLAS, and, optionally, MUMPS. By default it will assume that LAPACK and BLAS can be found under their usual names. MUMPS will be not linked against by default, except on Debian-based systems when the package
All these settings can be configured by creating/editing the file
build.confin the root directory of the distribution. This configuration file consists of sections, one for each dependency, led by a [dependency-name] header and followed by name = value entries. Possible names are keyword arguments for
distutils.core.Extension(For a complete list, see the third table from top of
this document <http://docs.python.org/distutils/apiref.html>_). The corresponding values are whitespace-separated lists of strings.
The two currently possible sections are [lapack] and [mumps]. The former configures the linking against LAPACK AND BLAS, the latter against MUMPS (without LAPACK and BLAS).
build.conffor linking against a self-compiled MUMPS,
SCOTCH <http://www.labri.fr/perso/pelegrin/scotch/>_ and
[mumps] libraries = zmumps mumps_common pord metis esmumps scotch scotcherr mpiseq gfortran
build.conffor linking with Intel MKL.::
[lapack] libraries = mkl_intel_lp64 mkl_sequential mkl_core mkl_def library_dirs = /opt/intel/mkl/lib/intel64 extra_link_args = -Wl,-rpath=/opt/intel/mkl/lib/intel64
The detailed syntax of
build.confis explained in the
documentation of Python's configparser module <http://docs.python.org/3/library/configparser.html#supported-ini-file-structure>_.
I compiled MUMPS and rebuilt the module, using a build.conf like this:
[mumps] libraries = zmumps mumps_common pord library_dirs = /*path_to_mumps_compilation*/lib /*path_to_mumps_compilation*/libseq include_dirs = /*path_to_mumps_compilation*/include extra_link_args = -Wl,-rpath=/*path_to_mumps_compilation*/lib
upon reinstalling the module and importing in python, I get an import error:
/*path_to*/_mumps.so: undefined symbol: mumps_get_mapping
upon examining _mumps.so, it seems the symbol is indeed undefined. This is the linking command of _mumps.so that was used during installation:
gcc -pthread -shared build/temp.linux-i686-2.7/kwant/linalg/_mumps.o -L/u/fphys/iw386/rt/lib -lmumps_common -lzmumps -lpord -lmetis -lesmumps -lscotch -lscotcherr -lmpiseq -llapack -lblas -o build/lib.linux-i686-2.7/kwant/linalg/_mumps.so -Wl,-rpath=/u/fphys/iw386/rt/lib
Note that mumps_common is loaded and mumps_get_mapping is not undefined in libmumps_common.a:
$ nm -g rt/lib/libmumps_common.a |grep mumps_get_mapping 00000000 T mumps_get_mapping
I am not quite sure about what a "tentative symbol" is. Does this also mean undefined?
I then tried also installing scotch and metis by building them from source (as is suggested in the example in the INSTALL file) and using this build.conf:
[mumps] libraries = zmumps mumps_common pord metis esmumps scotch scotcherr mpiseq gfortran library_dirs = /u/fphys/iw386/rt/lib include_dirs = /u/fphys/iw386/rt/include extra_link_args = -Wl,-rpath=/u/fphys/iw386/rt/lib
where all the libraries have been moved to /u/fphys/iw386/rt/lib and all the header files to /u/fphys/iw386/rt/include
The error message upon importing has now changed to
_mumps.so: undefined symbol: for_write_seq_lis
for_write_seq_lis seems to be a fortran-related method. However, the gfortran library file that I used was the one provided by the system via the gfortran package. I would rather like to avoid attempting to build gfortran and gcc and their dependencies from source.
Any help would be appreciated.