Re: [gentoo-science] sci-libs/scipy-0.9.0-r1 undefined symbol: clapack_sgesv

[Marc Vinyals <marcvinyals@velodius.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2885 bytes --]

EL Thu, 2 Jun 2011 07:22:18 +1200
Francois Bissey <fbissey@slingshot.co.nz> escrigué:

> > EL Wed, 1 Jun 2011 06:57:03 +1200
> > 
> > Francois Bissey <fbissey@slingshot.co.nz> escrigué:
> > > > Hi,
> > > > 
> > > > While updating sage and python to 4.7 and 2.7, I hit a
> > > > variation of an old bug (see http://bugs.gentoo.org/195619):
> > > > scipy compiles with lapack-reference but is unusable. Running
> > > > in python
> > > > 
> > > > import scipy.optimize
> > > > 
> > > > fails with
> > > > 
> > > > [...]
> > > > 
> > > >     from scipy.linalg import clapack
> > > > 
> > > > ImportError:
> > > > /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so:
> > > > undefined symbol: clapack_sgesv
> > > > 
> > > > I tried rebuilding numpy and scipy with lapack provided
> > > > (eselect) by lapack-reference, blas provided by blas-reference,
> > > > cblas provided by gsl and with/without clapack with the same
> > > > result.
> > > > 
> > > > Then I tried rebuilding numpy and scipy with lapack, blas and
> > > > cblas provided (eselect) by atlas and scipy worked flawlessly.
> > > > 
> > > > Should scipy depend on a specific lapack provider instead of a
> > > > virtual? Enable it at compile time? Is it an unfortunate
> > > > combination what fails?
> > > > 
> > > > I can provide build logs if you need them.
> > > 
> > > Hi Marc,
> > > 
> > > Just one thing that I can think of on the top of my head. We
> > > recently made scipy depend on arpack and superlu. They also have
> > > dependencies on blas/lapack if you didn't rebuild them as well
> > > they may cause trouble.
> > > 
> > > I had a similar problem recently but eselecting everything
> > > properly worked for me. A last piece of info you could provide:
> > > are you using the main tree implementation or bicatali's overlay
> > > implementation?
> > > 
> > > Francois
> > 
> > Hi Francois,
> > 
> > I tried rebuilding arpack and superlu without luck. Since you
> > mentioned that eselect fixed your problems, I also tried installing
> > cblas-reference and using it instead of gsl, also without luck.
> > 
> > I'm using the main tree implementation.
> > 
> Hi Marc,
> 
> I have been using bicatali's overlay for a bit and I recompiled all
> the cblas/lapack stack from sage a few times with different
> implementations in the last few days. The only time i had an issue
> was when the value eselected was not what I wanted by accident.
> 
> I am curious to see your build log for numpy and scipy. Also what
> does ldd /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so
> reports?
> 
> Francois
> 

Here are my logs. You'll find some warnings in the configuration
stage, I hope they'll mean something to you. Also, there's no trace of
libclapack.so in
ldd /usr/lib64/python2.7/site-packages/scipy/linalg/clapack.so.

[-- Attachment #1.2: dev-python:numpy-1.6.0:20110602-095859.log.bz2 --]
[-- Type: application/x-bzip, Size: 15878 bytes --]

[-- Attachment #1.3: sci-libs:scipy-0.9.0-r1:20110602-100122.log.bz2 --]
[-- Type: application/x-bzip, Size: 52433 bytes --]

[-- Attachment #1.4: ldd-clapack --]
[-- Type: application/octet-stream, Size: 448 bytes --]

	linux-vdso.so.1 =>  (0x00007fffd3716000)
	libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007f574b7b6000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f574b42a000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f574b20c000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f574b008000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00007f574ae05000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f574ab81000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f574bdd1000)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]