On Tue, 2005-05-10 at 16:39 -0400, Darren Dale wrote:
On Tuesday 10 May 2005 3:37 pm, Christopher G. Traylor wrote:
> Sorry, if this has been addressed before. We're trying to build scipy on
> an dual opteron box in 64 bit mode. With the r1 ebuild, it fails
> complaining that it can't find some symbol. If I take the atlas-3.6.0
> requirement out, it builds fine, but during the test phase, it gives
> these errors. My guess is that having atlas in there is causing some
> sort of multilib problem, and that blas-atlas provides all the required
> symbols, but doesn't have the proper internal support to return the
> answers that the scipy test suite is expecting. I guess my confusion
> stems from the whole "odd" virtual atlas set up. Any guidance would be
> appreciated.
sci-libs/atlas will, if installed after lapack-atlas, overwrite a symlink
in /usr/lib with an incomplete lapack library. atlas should not be in the
ebuild. Only lapack-atlas should be in there, which still provides the atlas
libraries. I wrote about this in the bug report.
Try running ls -l /usr/lib/liblapack.*, they should all be symlinks to files
in /usr/lib/lapack/atlas/. If, in /usr/lib, liblapack.a (I think .a) is not a
symlink, it is probably smaller than ~5.5MB, and isnt a full lapack
implementation.
Right. All three are symlinks. Although my thinking is that if the library was missing a function, then you would have had a segfault or some other "catastrophic" error like a failed build/link. I doubt something like that would cause an accuracy problem. I was more thinking of a problem with fixed size data elements (i.e. assuming a 32 bit long and a 64 bit long long, or something along those lines).
I am going to update the scipy ebuild as soon as the numeric ebuild is settled
(it appears that this will happen soon.) There are also two patches that
needs to be applied. I'll post them at the bug page:
http://bugs.gentoo.org/show_bug.cgi?id=24593
I added the patches to my ebuild file, and everything seems to go fine until the testing phase. Then I get an Xlib failure. It spits out that it couldn't connect to :0.0, and that no protocol was specified (i.e. typical useless X error message). My first question was why is the ebuild trying to launch a graphical app on install (although, I didn't specify it quite that politely when I realized it<g>)? Is there possibly some use flag that needs set so that the test suite allows it to run in a text mode that I'm retardedly omitting? Also, I was wondering whether I should bother with a bug report on this since we are talking about this directly.
>
> <snip>
> ======================================================================
> ERROR: check_simple_overdet (scipy.linalg.basic.test_basic.test_lstsq)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_basic.py",
> line 361, in check_simple_overdet
> x,res,r,s = lstsq(a,b)
> File "/usr/lib/python2.3/site-packages/scipy/linalg/basic.py", line
> 353, in lstsq
> if rank==n: resids = sum(x[n:]**2)
> ArithmeticError: Integer overflow in power.
>
> ======================================================================
> FAIL: check_simple (scipy.linalg.basic.test_basic.test_det)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_basic.py",
> line 273, in check_simple
> assert_almost_equal(a_det,-2.0)
> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line
> 606, in assert_almost_equal
> assert round(abs(desired - actual),decimal) == 0, msg
> AssertionError:
> Items are not equal:
> DESIRED: -2.0
> ACTUAL: -0.0
>
> ======================================================================
> FAIL: check_simple_exact (scipy.linalg.basic.test_basic.test_lstsq)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_basic.py",
> line 356, in check_simple_exact
> assert_array_almost_equal(Numeric.matrixmultiply(a,x),b)
> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line
> 684, in assert_array_almost_equal
> assert cond,\
> AssertionError:
> Arrays are not almost equal (mismatch 50.0%):
> Array 1: [0 0]
> Array 2: [1 0]
>
>
> ======================================================================
> FAIL: check_simple (scipy.linalg.basic.test_basic.test_solve)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_basic.py",
> line 74, in check_simple
> assert_array_almost_equal(Numeric.matrixmultiply(a,x),b)
> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line
> 684, in assert_array_almost_equal
> assert cond,\
> AssertionError:
> Arrays are not almost equal (mismatch 50.0%):
> Array 1: [-9223372036854775808 0]
> Array 2: [1 0]
>
>
> ======================================================================
> FAIL: check_simple_sym (scipy.linalg.basic.test_basic.test_solve)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/usr/lib/python2.3/site-packages/scipy/linalg/tests/test_basic.py",
> line 81, in check_simple_sym
> assert_array_almost_equal(Numeric.matrixmultiply(a,x),b)
> File "/usr/lib/python2.3/site-packages/scipy_test/testing.py", line
> 684, in assert_array_almost_equal
> assert cond,\
> AssertionError:
> Arrays are not almost equal (mismatch 100.0%):
> Array 1: [-9223372036854775784 -9223372036854775770]
> Array 2: [1 0]
>
>
> ----------------------------------------------------------------------
> <snip>
