[Numpy-discussion] glibc error

[Gideon Simpson]

Rebuilding the library against ATLAS 3.8.2 with lapack 3.1.1 seems to  
have done the trick.  I do get one failure:

======================================================================
FAIL: test_umath.TestComplexFunctions.test_against_cmath
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/usr/local/nonsystem/simpson/lib/python2.5/site-packages/nose/ 
case.py", line 182, in runTest
     self.test(*self.arg)
   File "/usr/local/nonsystem/simpson/lib/python2.5/site-packages/ 
numpy/core/tests/test_umath.py", line 268, in test_against_cmath
     assert abs(a - b) < atol, "%s %s: %s; cmath: %s"%(fname,p,a,b)
AssertionError: arcsinh -2j: (-1.31695789692-1.57079632679j); cmath:  
(1.31695789692-1.57079632679j)

----------------------------------------------------------------------


-gideon

On Jan 25, 2009, at 5:46 AM, Michael Abshoff wrote:

> David Cournapeau wrote:
>> Hoyt Koepke wrote:
>
> <SNIP>
>
>> Actually, I would advise using only 3.8.2. Previous versions had bugs
>> for some core routines used by numpy (at least 3.8.0 did). I am a bit
>> surprised that a 64 bits-built atlas would be runnable at all in a 32
>> bits binary - I would expect the link phase to fail if two different
>> object formats are linked together.
>
> Linking 32 and 64 bit ELF objects together in an extension will fail  
> on
> any system but OSX where the ld will happily link together anything.
> Since that linker also does missing symbol lookup at runtime you will
> see some surprising distutils bugs when you thought that the build  
> went
> perfectly, i.e. scipy 0.6 would not use the fortran compiler I would
> tell it to use, but one extension would use gfortran instead of
> sage_fortran when it was available in $PATH. sage_fortran would would
> just inject an "-m64" into the options and call gfortran. But with a  
> few
> fortran objects being 32 bit some extensions in scipy would fail to
> import and it took me quite a while to track this one down. I haven't
> had time to test 0.7rc2 yet, but hopefully will do so in the next  
> day or
> two.
>
>> cheers,
>>
>> David
>
> Cheers,
>
> Michael
>
>> _______________________________________________
>> Numpy-discussion mailing list
>> Numpy-discussion at scipy.org
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion