On Fri, Feb 22, 2008 at 8:40 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi! Unfortunately I don't think I'll manage to investigate this further > today, I'll try to have a look at it in the week end. > > Regarding the _dotblas.so problem: > - on an etch system > $ ldd /usr/lib/python2.4/site-packages/numpy/core/_dotblas.so > linux-gate.so.1 => (0xffffe000) > liblapack.so.3 => /usr/lib/atlas/sse2/liblapack.so.3 (0xb794e000) > libblas.so.3 => /usr/lib/atlas/sse2/libblas.so.3 (0xb7370000) > libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb735e000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb722d000) > libg2c.so.0 => /usr/lib/libg2c.so.0 (0xb7205000) > /lib/ld-linux.so.2 (0x80000000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb71df000) > and > $ ldd /usr/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so > linux-gate.so.1 => (0xffffe000) > liblapack.so.3 => /usr/lib/atlas/sse2/liblapack.so.3 (0xb7919000) > libblas.so.3 => /usr/lib/atlas/sse2/libblas.so.3 (0xb733b000) > libg2c.so.0 => /usr/lib/libg2c.so.0 (0xb7313000) > libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb72ee000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb72e3000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb71b2000) > /lib/ld-linux.so.2 (0x80000000) > > - on a sid system the _dotblas.so file is missing, and : > $ ldd /usr/lib/python2.4/site-packages/numpy/linalg/lapack_lite.so > linux-gate.so.1 => (0xffffe000) > liblapack.so.3gf => /usr/lib/sse2/atlas/liblapack.so.3gf (0xb7844000) > libblas.so.3gf => /usr/lib/sse2/atlas/libblas.so.3gf (0xb7274000) > libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb71cc000) > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb71a7000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb719a000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb704d000) > /lib/ld-linux.so.2 (0x80000000) > which is right, I think. If I recall correctly, _dotblas.so is built only if > lapack libraries are found when numpy is built. But the linalg module is > linked against lapack, so I really don't see why dotblas was not built. > > Concerning the ATLAS problem: installing the liblapack3-dev package made it > possible to compile external modules linking to ATLAS using f2py, so sorry. > that was my mistake. But since python-numpy now provides python-numpy-dev, I > would suggest to add a Depends: liblapack3-dev. An example of such an > extension module is my symeig package: > http://mdp-toolkit.sourceforge.net/symeig.html > building without liblapack3-dev results in a failure to import the module. > Instructions for building can be found on the web site. > > > let me know if you need further details,
Thanks for the details. Unfortunately, I am not an expert in this blas, dotblas, ... thing. So what is the problem in concrete terms - missing liblapack3-dev depends? There doesn't seem to by andy "liblapack3-dev" package in unstable. If you tell me exactly what to fix, I'll do that. Kumar (<- he is the expert:), any thoughts on this? Ondrej _______________________________________________ Python-modules-team mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
