linking problems when installing python module and dependencies as non-root

linking problems when installing python module and dependencies as non-root

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.