[SciPy-user] how to import umfpack?

2 views
Skip to first unread message

Robin

unread,
Feb 11, 2008, 10:52:26 AM2/11/08
to SciPy Users List
Hi,

I just setup a fresh svn install on a new machine, and I'm having
trouble getting some code to work (Im sure its something simple!)

Previously I was doing
import scipy.linsolve.umfpack as um

but I was expecting to have to change this soon with the move to splinalg.

However in the new version, although it umfpack appears to have build
successfully and there are files in splinalg/dsolve/umfpack (including
__umfpack.so) I can't import it.
import scipy.splinalg.dsolve.umfpack as um
fails ('module' object has no attribute 'umfpack')

How can I get at umfpack now?

Thanks

Robin
_______________________________________________
SciPy-user mailing list
SciPy...@scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-user

Robert Cimrman

unread,
Feb 11, 2008, 11:08:09 AM2/11/08
to SciPy Users List
Robin wrote:
> However in the new version, although it umfpack appears to have build
> successfully and there are files in splinalg/dsolve/umfpack (including
> __umfpack.so) I can't import it.
> import scipy.splinalg.dsolve.umfpack as um
> fails ('module' object has no attribute 'umfpack')

This should work, I do the same. Just tried with '0.7.0.dev3913'.

r.

Robin

unread,
Feb 11, 2008, 11:22:35 AM2/11/08
to SciPy Users List
On Feb 11, 2008 4:08 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
> This should work, I do the same. Just tried with '0.7.0.dev3913'.

Actually I've upgraded my laptop and it works there with
'0.7.0.dev3913' but on this new install (64 bit Linux) I still have
this problem.

As far as I can see umfpack has built correctly:
robince@bob64:/usr/lib/python2.5/site-packages/scipy/splinalg/dsolve/umfpack$ ls
info.py __init__.py setup.py tests umfpack.py umfpack.pyc
info.pyc __init__.pyc setup.pyc _umfpack.py _umfpack.pyc __umfpack.so

and a simple grep for umfpack in dsolve doesn't show any difference
between the working and non-working one.
However:

In [2]: scipy.__version__
Out[2]: '0.7.0.dev3912'

In [3]: import scipy.splinalg.dsolve.umfpack as um
---------------------------------------------------------------------------
<type 'exceptions.AttributeError'> Traceback (most recent call last)

/home/robince/<ipython console> in <module>()

<type 'exceptions.AttributeError'>: 'module' object has no attribute 'umfpack'

In [4]: import scipy.splinalg.dsolve as dsolve

In [5]: dir(dsolve)
Out[5]:
['SparseEfficiencyWarning',
'Tester',
'__all__',
'__builtins__',
'__doc__',
'__file__',
'__name__',
'__path__',
'_csuperlu',
'_dsuperlu',
'_ssuperlu',
'_superlu',
'_zsuperlu',
'asarray',
'csc_matrix',
'factorized',
'isUmfpack',
'isspmatrix',
'isspmatrix_csc',
'isspmatrix_csr',
'linsolve',
'splu',
'spsolve',
'superLU_transtabl',
'test',
'useUmfpack',
'use_solver',
'warn']

I'd appreciate any help/suggestions to get this working - the
problematic new install is on a powerful machine I only have access
too for a limited time so I'd like to get it running as soon as
possible.

Thanks,

Robin

Robert Cimrman

unread,
Feb 11, 2008, 11:28:37 AM2/11/08
to SciPy Users List
Robin wrote:
> On Feb 11, 2008 4:08 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
>> This should work, I do the same. Just tried with '0.7.0.dev3913'.
>
> Actually I've upgraded my laptop and it works there with
> '0.7.0.dev3913' but on this new install (64 bit Linux) I still have
> this problem.
>
> As far as I can see umfpack has built correctly:
> robince@bob64:/usr/lib/python2.5/site-packages/scipy/splinalg/dsolve/umfpack$ ls
> info.py __init__.py setup.py tests umfpack.py umfpack.pyc
> info.pyc __init__.pyc setup.pyc _umfpack.py _umfpack.pyc __umfpack.so
>
> and a simple grep for umfpack in dsolve doesn't show any difference
> between the working and non-working one.
> However:
>
> In [2]: scipy.__version__
> Out[2]: '0.7.0.dev3912'
>
> In [3]: import scipy.splinalg.dsolve.umfpack as um
> ---------------------------------------------------------------------------
> <type 'exceptions.AttributeError'> Traceback (most recent call last)
>
> /home/robince/<ipython console> in <module>()
>
> <type 'exceptions.AttributeError'>: 'module' object has no attribute 'umfpack'
> ...

> I'd appreciate any help/suggestions to get this working - the
> problematic new install is on a powerful machine I only have access
> too for a limited time so I'd like to get it running as soon as
> possible.

Did it work on the other computer with some older version of scipy?
Is there the umfpack proper installed, actually (libumfpack.a, or .so)?

r.

Robin

unread,
Feb 11, 2008, 11:41:37 AM2/11/08
to SciPy Users List
On Feb 11, 2008 4:28 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
> Did it work on the other computer with some older version of scipy?
> Is there the umfpack proper installed, actually (libumfpack.a, or .so)?

I've had problems on the new install with 0.7.0.dev3912 and
0.7.0.dev3913. (on 64 bit linux)
It works for me on my latop - mac os x, 0.7.0.dev3913

I build libumfpack.a and scipy finds it and builds without errors.
useUmfPack is set to True, it just seems that dsolve doesn't have a
umfpack attribute.

Here is the relevant output from the distutils config:
FOUND:
libraries = ['amd']
library_dirs = ['/home/robince/scipy_build/lib']
swig_opts = ['-I/home/robince/scipy_build/lib/include']
define_macros = [('SCIPY_AMD_H', None)]
include_dirs = ['/home/robince/scipy_build/lib/include']

FOUND:
libraries = ['umfpack', 'amd']
library_dirs = ['/home/robince/scipy_build/lib']
swig_opts = ['-I/home/robince/scipy_build/lib/include',
'-I/home/robince/scipy_build/lib/include']
define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]
include_dirs = ['/home/robince/scipy_build/lib/include']

Robin

Robert Cimrman

unread,
Feb 11, 2008, 11:49:00 AM2/11/08
to SciPy Users List
Robin wrote:
> On Feb 11, 2008 4:28 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
>> Did it work on the other computer with some older version of scipy?
>> Is there the umfpack proper installed, actually (libumfpack.a, or .so)?
>
> I've had problems on the new install with 0.7.0.dev3912 and
> 0.7.0.dev3913. (on 64 bit linux)
> It works for me on my latop - mac os x, 0.7.0.dev3913
>
> I build libumfpack.a and scipy finds it and builds without errors.
> useUmfPack is set to True, it just seems that dsolve doesn't have a
> umfpack attribute.

This is probably caused by the following lines in
splinalg/dsolve/umfpack/umpfack.py:

try: # Silence import error.
import _umfpack as _um
except:
_um = None

Try moving the import line out of the try-except statement to see what
actually went wrong when importing the shared library _umfpack.

r.

Nathan Bell

unread,
Feb 11, 2008, 11:52:23 AM2/11/08
to SciPy Users List
On Feb 11, 2008 10:41 AM, Robin <rob...@gmail.com> wrote:
> I've had problems on the new install with 0.7.0.dev3912 and
> 0.7.0.dev3913. (on 64 bit linux)
> It works for me on my latop - mac os x, 0.7.0.dev3913

No problems for me with '0.7.0.dev3912' on 64-bit linux.

> I build libumfpack.a and scipy finds it and builds without errors.
> useUmfPack is set to True, it just seems that dsolve doesn't have a
> umfpack attribute.

I don't know what could cause that.

By "new install" do you mean that you've removed scipy/build and
/usr/lib/python2.5/site-packages/scipy* ?

--
Nathan Bell wnb...@gmail.com
http://graphics.cs.uiuc.edu/~wnbell/

Robin

unread,
Feb 11, 2008, 12:39:05 PM2/11/08
to SciPy Users List
On Feb 11, 2008 4:49 PM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
> Try moving the import line out of the try-except statement to see what
> actually went wrong when importing the shared library _umfpack.

Thanks, this revealed an error:
<type 'exceptions.ImportError'>:
/usr/lib/python2.5/site-packages/scipy/splinalg/dsolve/umfpack/__umfpack.so:
undefined symbol: _gfortran_st_write_done

I linked umf against gfortran as seemed to be required in UFconfig.mk,
and also need to add
-L/usr/lib/gcc/x86_64-linux-gnu/4.2.1 flag to get the umf build to
find libgfortran.

I guess this is the problem. I tried setting
export LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.2.1
hoping this would let the import pick it up at runtime but it didn't
seem to work.

On Feb 11, 2008 4:52 PM, Nathan Bell <wnb...@gmail.com> wrote:
> By "new install" do you mean that you've removed scipy/build and
> /usr/lib/python2.5/site-packages/scipy* ?

By new install I mean the machine didn't have any numpy/scipy stuff on
it before so lapack, atlas, umfpack are all installed fresh (rather
than working then broken with an update).

Thanks again,

Robin

Robin

unread,
Feb 11, 2008, 12:46:09 PM2/11/08
to SciPy Users List
Having googled a bit, I thought I should add I don't think is due to
mixing compilers, g77 isn't installed, only gfortran, so as far as I
know everything (ATLAS, umf, scipy) is built with that. (lapack atlas
etc all built from source, gfortran standard ubuntu version)

Robin

unread,
Feb 11, 2008, 3:02:22 PM2/11/08
to SciPy Users List
So I've tried to play around with rebuilding UMFPACK and scipy, but
haven't had any luck.

In UFconfig.mk this is my BLAS and LAPACK settings:
BLAS = -L/usr/lib/gcc/x86_64-linux-gnu/4.2.1
-L/home/robince/scipy_build/lib -llapack -lf77blas -lcblas -latlas
-lgfortran
LAPACK = -L/usr/lib/gcc/x86_64-linux-gnu/4.2.1
-L/home/robince/scipy_build/lib -llapack -lf77blas -lcblas -latlas
-lgfortran

Also CFLAGS = -O3 -fPIC -m64 -fexceptions

This is the only way I have been able to get UMFPACK to build,
anything I tried to change (about linking with gfortran) caused build
errors).

For Lapack I added -fPIC and -m64 to all the FLAGS and otherwise used
the make.inc.gfortran values.

For ATLAS I used the following configure command:
../configure -b 64 -Fa alg -fPIC
--with-netlib-lapack=/home/robince/scipy_build/lapack-3.1.1/lapack_LINUX.a

For scipy:
python setup.py build
and from the config output it is picking up gfortran, ATLAS, UMFPACK, AMD ok.
Build completed without errors.

Any ideas where I'm going wrong that is causing this problem with
gfortran symbols when import umfpack? The only thing I can think is
that it is to do with libgfortran being in a funny place
(/usr/lib/gcc/x86_64-linux-gnu/4.2.1), but as I mentioned earlier
LD_LIBRARY_PATH doesn't seem to make any difference.

Here is ldd -r on __umfpack.so if it can through any light. ldd
doesn't report any dependency from __umfpack.so on libgfortran anyway
- how should that get there? (at which stage). I have to admit I'm
reaching the limits of my knowledge in terms of building/shared
libraries (as I always seem to when trying to build numpy/scipy!)

robince@bob64:/usr/lib/python2.5/site-packages/scipy/splinalg/dsolve/umfpack$
ldd -r __umfpack.so
undefined symbol: PyObject_GenericGetAttr (./__umfpack.so)
undefined symbol: PyExc_ImportError (./__umfpack.so)
undefined symbol: PyExc_ValueError (./__umfpack.so)
undefined symbol: PyInstance_Type (./__umfpack.so)
undefined symbol: PyExc_SystemError (./__umfpack.so)
undefined symbol: PyList_Type (./__umfpack.so)
undefined symbol: PyExc_TypeError (./__umfpack.so)
undefined symbol: PyInt_Type (./__umfpack.so)
undefined symbol: _PyWeakref_CallableProxyType (./__umfpack.so)
undefined symbol: PyExc_SyntaxError (./__umfpack.so)
undefined symbol: PyExc_ZeroDivisionError (./__umfpack.so)
undefined symbol: PyExc_IndexError (./__umfpack.so)
undefined symbol: PyExc_MemoryError (./__umfpack.so)
undefined symbol: PyTuple_Type (./__umfpack.so)
undefined symbol: PyExc_RuntimeError (./__umfpack.so)
undefined symbol: PyType_Type (./__umfpack.so)
undefined symbol: PyExc_IOError (./__umfpack.so)
undefined symbol: PyLong_Type (./__umfpack.so)
undefined symbol: _Py_NoneStruct (./__umfpack.so)
undefined symbol: PyExc_OverflowError (./__umfpack.so)
undefined symbol: PyExc_AttributeError (./__umfpack.so)
undefined symbol: _PyWeakref_ProxyType (./__umfpack.so)
undefined symbol: PyCObject_Type (./__umfpack.so)
undefined symbol: PyModule_AddObject (./__umfpack.so)
undefined symbol: PyDict_SetItemString (./__umfpack.so)
undefined symbol: PyString_AsString (./__umfpack.so)
undefined symbol: PyArg_UnpackTuple (./__umfpack.so)
undefined symbol: sqrt (./__umfpack.so)
undefined symbol: _gfortran_st_write_done (./__umfpack.so)
undefined symbol: Py_InitModule4_64 (./__umfpack.so)
undefined symbol: PyLong_FromVoidPtr (./__umfpack.so)
undefined symbol: _gfortran_transfer_integer (./__umfpack.so)
undefined symbol: PyCObject_FromVoidPtr (./__umfpack.so)
undefined symbol: PyBool_FromLong (./__umfpack.so)
undefined symbol: ceil (./__umfpack.so)
undefined symbol: _PyObject_GetDictPtr (./__umfpack.so)
undefined symbol: PyObject_CallFunctionObjArgs (./__umfpack.so)
undefined symbol: PyObject_IsTrue (./__umfpack.so)
undefined symbol: PyString_FromStringAndSize (./__umfpack.so)
undefined symbol: PyLong_AsLong (./__umfpack.so)
undefined symbol: PyCObject_Import (./__umfpack.so)
undefined symbol: PyErr_Format (./__umfpack.so)
undefined symbol: PyFloat_FromDouble (./__umfpack.so)
undefined symbol: PyArg_ParseTuple (./__umfpack.so)
undefined symbol: PyObject_GetAttr (./__umfpack.so)
undefined symbol: PyErr_Occurred (./__umfpack.so)
undefined symbol: _gfortran_stop_numeric (./__umfpack.so)
undefined symbol: _PyInstance_Lookup (./__umfpack.so)
undefined symbol: _gfortran_st_write (./__umfpack.so)
undefined symbol: PySequence_Concat (./__umfpack.so)
undefined symbol: PyString_FromString (./__umfpack.so)
undefined symbol: PyString_FromFormat (./__umfpack.so)
undefined symbol: PyInt_FromLong (./__umfpack.so)
undefined symbol: PyModule_GetDict (./__umfpack.so)
undefined symbol: PyDict_GetItem (./__umfpack.so)
undefined symbol: PyInt_AsLong (./__umfpack.so)
undefined symbol: PyCObject_AsVoidPtr (./__umfpack.so)
undefined symbol: PyType_IsSubtype (./__umfpack.so)
undefined symbol: PyObject_Init (./__umfpack.so)
undefined symbol: PyObject_Malloc (./__umfpack.so)
undefined symbol: PyObject_GetAttrString (./__umfpack.so)
undefined symbol: PyList_Append (./__umfpack.so)
undefined symbol: PyObject_Call (./__umfpack.so)
undefined symbol: PyErr_Print (./__umfpack.so)
undefined symbol: PyString_ConcatAndDel (./__umfpack.so)
undefined symbol: PyObject_Free (./__umfpack.so)
undefined symbol: PyImport_ImportModule (./__umfpack.so)
undefined symbol: PyErr_Clear (./__umfpack.so)
undefined symbol: PyTuple_New (./__umfpack.so)
undefined symbol: PyTuple_SetItem (./__umfpack.so)
undefined symbol: PyErr_SetString (./__umfpack.so)
undefined symbol: _gfortran_transfer_character (./__umfpack.so)
undefined symbol: PyList_SetItem (./__umfpack.so)
undefined symbol: PyInstance_NewRaw (./__umfpack.so)
undefined symbol: PyList_New (./__umfpack.so)
undefined symbol: PyString_Format (./__umfpack.so)
undefined symbol: PyDict_SetItem (./__umfpack.so)
undefined symbol: PyDict_New (./__umfpack.so)
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b23f84ed000)
libc.so.6 => /lib/libc.so.6 (0x00002b23f8708000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

Thanks again,

Martin Lüthi

unread,
Feb 11, 2008, 4:48:54 PM2/11/08
to scipy...@scipy.org
Hi

Robin <rob...@gmail.com> writes:

> I just setup a fresh svn install on a new machine, and I'm having

Is this on Ubuntu? I had to change the site.cfg file to

[umfpack]
umfpack_libs = umfpack
include_dirs = /usr/include/suitesparse

HTH


--
Martin Lüthi ans...@tnoo.net

Robin

unread,
Feb 11, 2008, 5:10:07 PM2/11/08
to ans...@tnoo.net, SciPy Users List
On Feb 11, 2008 9:48 PM, Martin Lüthi <ans...@tnoo.net> wrote:
> Hi

>
> Robin <rob...@gmail.com> writes:
> Is this on Ubuntu? I had to change the site.cfg file to
>
> [umfpack]
> umfpack_libs = umfpack
> include_dirs = /usr/include/suitesparse
>
> HTH

Thanks, it is on Ubuntu. Here is my site.cfg. I don't have that, but I
have the amd and umfpack headers in
/home/robince/scipy_build/libs/include which is added to the default
include path. I think this is OK - I would have thought I would get
errors during the build if it wasn't finding some header files.

[DEFAULT]
library_dirs = /usr/local/lib:/home/robince/scipy_build/lib
include_dirs = /usr/local/include:/home/robince/scipy_build/lib/include

[atlas]
atlas_libs = lapack, f77blas, cblas, atlas

[amd]
amd_libs = amd

[umfpack]
umfpack_libs = umfpack

[fftw]
libraries = fftw3

Robin

unread,
Feb 11, 2008, 5:19:06 PM2/11/08
to SciPy Users List
I don't know if it could be related (or whether I should start a
seperate thread) but also scipy.test() doesn't pick up any tests with
this installation. I have installed the ubuntu python-nose package. Is
there anything else that is needed?

In [2]: scipy.__version__
Out[2]: '0.7.0.dev3913'

In [3]: scipy.test()

----------------------------------------------------------------------
Ran 0 tests in 0.005s

OK

In [5]: scipy.test(label='full')

----------------------------------------------------------------------
Ran 0 tests in 0.004s

OK

Martin Lüthi

unread,
Feb 11, 2008, 5:21:19 PM2/11/08
to scipy...@scipy.org
Robin <rob...@gmail.com> writes:

> On Feb 11, 2008 9:48 PM, Martin Lüthi <ans...@tnoo.net> wrote:
>> Robin <rob...@gmail.com> writes:
>> Is this on Ubuntu? I had to change the site.cfg file to
>>
>> [umfpack]
>> umfpack_libs = umfpack
>> include_dirs = /usr/include/suitesparse
>

> Thanks, it is on Ubuntu. Here is my site.cfg. I don't have that, but I
> have the amd and umfpack headers in

Oh, I must have missed that you installed the libraries yourself. The
above entry is the only thing I had to add to site.cfg, having installed
libsuitesparse[-dev] (which includes UMFpack). As for Atlas I used
thought you atlas3-ss2-dev.

Best, Martin

--
Martin Lüthi ans...@tnoo.net

Matthew Brett

unread,
Feb 11, 2008, 6:19:51 PM2/11/08
to SciPy Users List
Hi,

On Feb 11, 2008 10:19 PM, Robin <rob...@gmail.com> wrote:
> I don't know if it could be related (or whether I should start a
> seperate thread) but also scipy.test() doesn't pick up any tests with
> this installation. I have installed the ubuntu python-nose package. Is
> there anything else that is needed?

Thanks for the report - I didn't know until Stefan pointed it out to
me recently that the older versions of nose run no tests - I've just
put a version check into SVN. You seem to need a version 0.10 at
least - I've got 0.10.1. easy_install might or might not get that
version for you, otherwise see:

http://somethingaboutorange.com/mrl/projects/nose/

Matthew

Robert Cimrman

unread,
Feb 12, 2008, 5:15:15 AM2/12/08
to SciPy Users List

In addition to what you have, I have this in the site.cfg:

[blas_opt]
libraries = f77blas, cblas, atlas

[lapack_opt]
library_dirs = /usr/lib
libraries = lapack, f77blas, cblas, atlas

ldd -r produces (no _gfortran_* undefined symbols, only the usual Py*...):
linux-gate.so.1 => (0xffffe000)
libumfpack.so.0 => /usr/lib/libumfpack.so.0 (0xb7df6000)
libamd.so.0 => /usr/lib/libamd.so.0 (0xb7de5000)
libblas.so.0 => /usr/lib/libblas.so.0 (0xb7dc9000)
libgfortran.so.1 =>
/usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libgfortran.so.1 (0xb7d4e000)
libm.so.6 => /lib/libm.so.6 (0xb7d27000)
libgcc_s.so.1 =>
/usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libgcc_s.so.1 (0xb7d1b000)
libc.so.6 => /lib/libc.so.6 (0xb7bea000)
libatlas.so.0 => /usr/lib/libatlas.so.0 (0xb781a000)
/lib/ld-linux.so.2 (0x80000000)


Otherwise all you do seems fine, I have no other clue what is the problem.

r.

Robin

unread,
Feb 12, 2008, 11:30:13 AM2/12/08
to SciPy Users List
On Feb 12, 2008 10:15 AM, Robert Cimrman <cimr...@ntc.zcu.cz> wrote:
>
> ldd -r produces (no _gfortran_* undefined symbols, only the usual Py*...):
> linux-gate.so.1 => (0xffffe000)
> libumfpack.so.0 => /usr/lib/libumfpack.so.0 (0xb7df6000)
> libamd.so.0 => /usr/lib/libamd.so.0 (0xb7de5000)
> libblas.so.0 => /usr/lib/libblas.so.0 (0xb7dc9000)
> libgfortran.so.1 =>
> /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libgfortran.so.1 (0xb7d4e000)
> libm.so.6 => /lib/libm.so.6 (0xb7d27000)
> libgcc_s.so.1 =>
> /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libgcc_s.so.1 (0xb7d1b000)
> libc.so.6 => /lib/libc.so.6 (0xb7bea000)
> libatlas.so.0 => /usr/lib/libatlas.so.0 (0xb781a000)
> /lib/ld-linux.so.2 (0x80000000)
>
>
> Otherwise all you do seems fine, I have no other clue what is the problem.

So it seems there are a lot of dependencies missing from my __umfpack.so:
robince@bob64:/usr/lib/python2.5/site-packages/scipy/splinalg/dsolve/umfpack$
ldd __umfpack.so
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b2cc544c000)
libc.so.6 => /lib/libc.so.6 (0x00002b2cc5667000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

(no umfpack, amd, atlas or gfortran)
And yet compilation and linking seemed to complete without errors. Is
there any way I can get more detail about the build process of the
umfpack module, perhaps try it by hand, or try to debug it further
(more verbose output seeing all the commands run to build it etc.)?

Thanks,

Robin

Robin

unread,
Feb 12, 2008, 11:45:49 AM2/12/08
to SciPy Users List
I was thinking that despite the lack of a dependency from __umfpack.so
to libumfpack, libamd, libatlas etc. there are no underfined
references shown by ldd -r (shown in earlier post) other than the Py*
and a couple of _gfortran functions. So it doesn't seem that there are
any umf related functions linked into this file.

Could there be something going wrong with distutils during the build
of the umfpack module?

I've also tried compiling UMFPACK many times, with every permutation
of options in UFconfig.mk that I can get to build successfully, but
each time (on rebuilding scipy, including deleting site_packages/scipy
and build directory) the result is the same.

Cheers,

Nils Wagner

unread,
Feb 12, 2008, 11:57:41 AM2/12/08
to SciPy Users List

Hi Robin,

I am using umfpackv4.4 without any problems.
I have compiled and installed umfpack from scratch.

My site.cfg consists of

[amd]
library_dirs=/home/nwagner/src/UMFPACKv4.4/AMD/Lib
include_dirs=/home/nwagner/src/UMFPACKv4.4/AMD/Include

[umfpack]
library_dirs=/home/nwagner/src/UMFPACKv4.4/UMFPACK/Lib
include_dirs=/home/nwagner/src/UMFPACKv4.4/UMFPACK/Include

Now umfpack is a scikits package

svn co http://svn.scipy.org/svn/scikits/trunk/umfpack
umfpack

Cheers,

Nils

Robert Cimrman

unread,
Feb 12, 2008, 12:04:41 PM2/12/08
to SciPy Users List

well, with shared libraries you get complains only when a symbol is
actually needed (i.e. when you import). Is it possible force linking the
libgfortran somehow? I do not know enough about the scipy build system
to give advice here.

r.

Robin

unread,
Feb 12, 2008, 12:17:44 PM2/12/08
to SciPy Users List
On Feb 12, 2008 4:57 PM, Nils Wagner <nwa...@iam.uni-stuttgart.de> wrote:
> Now umfpack is a scikits package
>
> svn co http://svn.scipy.org/svn/scikits/trunk/umfpack
> umfpack

Hi,

I tried building from the scikits package with exactly the same
results (no umfpack stuff in __umfpack.so, just Py* stuff and a couple
of _gfortran symbols.

The umfpack version I am using is the current from the website - I
think it is 5. I don't think the site.cfg is the problem, since the
headers and libraries are found OK (If I move them then they aren't
found and the build fails).
Somehow the problem must be with what distutils is doing to build the
__umfpack.so object? Is there any way I can get more detail about
this?

Below is the output of setup.py config for the umfpack scikit...

umfpack_info:
amd_info:
FOUND:
libraries = ['amd']
library_dirs = ['/home/robince/scipy_build/AMD/Lib']
swig_opts = ['-I/home/robince/scipy_build/AMD/Include']


define_macros = [('SCIPY_AMD_H', None)]

include_dirs = ['/home/robince/scipy_build/AMD/Include']

FOUND:
libraries = ['umfpack', 'amd']

library_dirs = ['/home/robince/scipy_build/UMFPACK/Lib',
'/home/robince/scipy_build/AMD/Lib']
swig_opts = ['-I/home/robince/scipy_build/UMFPACK/Include',
'-I/home/robince/scipy_build/AMD/Include']


define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]

include_dirs = ['/home/robince/scipy_build/UMFPACK/Include',
'/home/robince/scipy_build/AMD/Include']

blas_opt_info:
blas_mkl_info:
libraries mkl,vml,guide not found in /usr/local/lib
libraries mkl,vml,guide not found in /home/robince/scipy_build/lib
NOT AVAILABLE

atlas_blas_threads_info:
Setting PTATLAS=ATLAS
libraries lapack,f77blas,cblas,atlas not found in /usr/local/lib
Setting PTATLAS=ATLAS
Setting PTATLAS=ATLAS
FOUND:
libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
library_dirs = ['/home/robince/scipy_build/lib']
language = c

customize GnuFCompiler
Could not locate executable g77
Could not locate executable f77
customize IntelFCompiler
Could not locate executable ifort
Could not locate executable ifc
customize LaheyFCompiler
Could not locate executable lf95
customize PGroupFCompiler
Could not locate executable pgf90
Could not locate executable pgf77
customize AbsoftFCompiler
Could not locate executable f90
customize NAGFCompiler
Found executable /usr/bin/f95
customize VastFCompiler
customize GnuFCompiler
customize CompaqFCompiler
Could not locate executable fort
customize IntelItaniumFCompiler
Could not locate executable efort
Could not locate executable efc
customize IntelEM64TFCompiler
customize Gnu95FCompiler
Found executable /usr/bin/gfortran
customize Gnu95FCompiler
customize Gnu95FCompiler using config
compiling '_configtest.c':

/* This file is generated from numpy/distutils/system_info.py */
void ATL_buildinfo(void);
int main(void) {
ATL_buildinfo();
return 0;
}
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall
-Wstrict-prototypes -fPIC

compile options: '-c'
gcc: _configtest.c
gcc -pthread _configtest.o -L/home/robince/scipy_build/lib -llapack
-lf77blas -lcblas -latlas -o _configtest
ATLAS version 3.8.0 built by robince on Mon Feb 11 07:12:11 EST 2008:
UNAME : Linux bob64 2.6.22-14-generic #1 SMP Sun Oct 14 21:45:15
GMT 2007 x86_64 GNU/Linux
INSTFLG : -1 0 -a 1
ARCHDEFS : -DATL_OS_Linux -DATL_ARCH_Core2Duo -DATL_CPUMHZ=2333
-DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664
F2CDEFS : -DAdd_ -DF77_INTEGER=int -DStringSunStyle
CACHEEDGE: 131072
F77 : gfortran, version GNU Fortran (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu4)
F77FLAGS : -O -fPIC -m64
SMC : gcc, version gcc (GCC) 4.1.3 20070929 (prerelease)
(Ubuntu 4.1.2-16ubuntu2)
SMCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC -m64
SKC : gcc, version gcc (GCC) 4.1.3 20070929 (prerelease)
(Ubuntu 4.1.2-16ubuntu2)
SKCFLAGS : -fomit-frame-pointer -mfpmath=sse -msse3 -O2 -fPIC -m64
success!
removing: _configtest.c _configtest.o _configtest
FOUND:
libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
library_dirs = ['/home/robince/scipy_build/lib']
language = c
define_macros = [('ATLAS_INFO', '"\\"3.8.0\\""')]

running config

Robin

unread,
Feb 12, 2008, 2:15:32 PM2/12/08
to SciPy Users List
Hi,

I've made some progress...
I was able to get umfpack scikit to build properly. I found the -v
option to setup.py which gave more information about the command it's
running. Then by adding -lgfortran and appropriate -L option and
running the command again by hand, the resulting __umfpack.so didn't
have the unresolved symbols and scikits.umfpack could be installed
successfully. The command distutils runs is:

gcc -pthread -shared -Wl,-O1
build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/scikits/umfpack/_umfpack_wrap.o
-L/home/robince/scipy_build/UMFPACK/Lib
-L/home/robince/scipy_build/AMD/Lib -L/home/robince/scipy_build/lib
-lumfpack -lamd -llapack -lf77blas -lcblas -latlas -o
build/lib.linux-x86_64-2.5/scikits/umfpack/__umfpack.so

However to get it work I needed to add
-L/usr/lib/gcc/x86_64-linux-gnu/4.2.1 and -lgfortran:

gcc -pthread -shared -Wl,-O1
build/temp.linux-x86_64-2.5/build/src.linux-x86_64-2.5/scikits/umfpack/_umfpack_wrap.o
-L/home/robince/scipy_build/UMFPACK/Lib
-L/home/robince/scipy_build/AMD/Lib -L/home/robince/scipy_build/lib
-L/usr/lib/gcc/x86_64-linux-gnu/4.2.1 -lumfpack -lamd -llapack
-lf77blas -lcblas -latlas -lgfortran -o
build/lib.linux-x86_64-2.5/scikits/umfpack/__umfpack.so

Is there any way I can get distutils to add these commands so I don't
have to run the command by hand?

Thanks

Robin

Reply all
Reply to author
Forward
0 new messages