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:

Build configuration

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 libmumps-scotch-dev is installed.

All these settings can be configured by creating/editing the file build.conf in 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).

Example build.conf for linking against a self-compiled MUMPS, SCOTCH <http://www.labri.fr/perso/pelegrin/scotch/>_ and METIS <http://glaros.dtc.umn.edu/gkhome/metis/metis/overview>_::

[mumps]
libraries = zmumps mumps_common pord metis esmumps scotch scotcherr mpiseq
    gfortran

Example build.conf for 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.conf is 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.