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 configurationThe 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    gfortranExample build.conf for linking with Intel MKL.::[lapack]libraries = mkl_intel_lp64 mkl_sequential mkl_core mkl_deflibrary_dirs = /opt/intel/mkl/lib/intel64extra_link_args = -Wl,-rpath=/opt/intel/mkl/lib/intel64The 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*/libupon reinstalling the module and importing in python, I get an import error:/*path_to*/_mumps.so: undefined symbol: mumps_get_mappingupon 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/libNote 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_mappingI 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/libwhere all the libraries have been moved to /u/fphys/iw386/rt/lib and all the header files to /u/fphys/iw386/rt/includeThe error message upon importing has now changed to _mumps.so: undefined symbol: for_write_seq_lisfor_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.
linking problems when installing python module and dependencies as non-root
debian;compiling;python;not root user;dynamic linking