ligando problemas ao instalar o módulo python e dependências como não raiz

Question

Eu quero instalar um determinado módulo python (não-público, numérico) em um sistema remoto (Debian squeeze) no qual eu não tenho privilégios de root (ou sudo). Como o pacote python-dev não foi instalado, eu compilei e instalei localmente o python 2.7 (usando ./configure --prefix = $ HOME / rt). De igual modo, instalei numpy, scipy e tinyarray usando a opção --user de setup.py, pois são necessários. Depois, instalei o módulo, que não apresentou problemas. No entanto, ao importar o módulo em python, recebo a seguinte mensagem:

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.

Na verdade, o desempenho acabou sendo ruim. Após algumas pesquisas, descobriu-se que o módulo suporta o uso de umfpack e MUMPS. Ambos seriam aceitáveis, mas em sistemas diferentes, achei MUMPS ter um desempenho um pouco melhor. Eu não tive sucesso com a instalação de qualquer um. Em relação ao umfpack, eu não encontrei nenhuma informação sobre como instalá-lo além de um scipack para scipy que parece não existir mais.

Então, tentei instalar o MUMPS.

do arquivo INSTALL do módulo:

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>_.

Eu compilei o MUMPS e recompus o módulo, usando um build.conf assim:

   [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

Após reinstalar o módulo e importar em python, recebo um erro de importação:

/*path_to*/_mumps.so: undefined symbol: mumps_get_mapping

ao examinar _mumps.so, parece que o símbolo é de fato indefinido. Este é o comando de vinculação de _mumps.so que foi usado durante a instalação:

    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

Observe que o mumps_common está carregado e o mumps_get_mapping não está indefinido em libmumps_common.a:

    $ nm -g rt/lib/libmumps_common.a |grep mumps_get_mapping
    00000000 T mumps_get_mapping

Não tenho muita certeza sobre o que é um "símbolo tentativo". Isso também significa indefinido?

Eu tentei também instalar scotch e metis construindo-os a partir da fonte (como é sugerido no exemplo no arquivo INSTALL) e usando este 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

onde todas as bibliotecas foram movidas para / u / fphys / iw386 / rt / lib e todos os arquivos de cabeçalho para / u / fphys / iw386 / rt / include

A mensagem de erro ao importar agora mudou para

_mumps.so: undefined symbol: for_write_seq_lis

for_write_seq_lis parece ser um método relacionado a fortran. No entanto, o arquivo da biblioteca gfortran que eu usei era o fornecido pelo sistema através do pacote gfortran. Eu gostaria de evitar a tentativa de criar gfortran e gcc e suas dependências da fonte.

Qualquer ajuda seria apreciada.