Bug 478435

Summary: ndimage.histogram is broken for Fedora 9 and 10
Product: [Fedora] Fedora Reporter: vossman <vossman77>
Component: scipyAssignee: Jef Spaleta <jspaleta>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: jonathansteffan, jspaleta, jss
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.7.0-0.1.b1.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-24 20:59:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description vossman 2008-12-30 01:54:44 UTC
Description of problem:

I am part of science lab where we develop an open source product. Unfortunately, our software crashes for Fedora 8, 9 and 10 with Scipy v0.6. I narrowed the problem down to the ndimage.histogram function in Scipy. It works fine under Fedora 8 (with Scipy v0.6), RHEL 5 (with Scipy v0.5.2) and Ubuntu (according to Scipy site) 

I posted this bug on the Scipy Trac system:

http://scipy.org/scipy/scipy/ticket/824

but they say it works under Ubuntu for both 32 and 64-bit with Scipy v0.6 and v0.7.

=========
Version-Release number of selected component (if applicable):

Scipy v 0.6

=========
How reproducible:

Always

=========
Steps to Reproduce:
1. Run this script:

#!/usr/bin/env python
import sys
import scipy
import scipy.ndimage
import numpy
a = numpy.zeros((4,4))
a[1, 0:2] = 1
a[1:4, 3] = 2
print "python v", sys.version
print "numpy v", numpy.__version__
print "scipy v", scipy.__version__
print a
print "\nresult="
print scipy.ndimage.histogram(a, min=1, max=3, bins=2)

=========
Actual results:
A machine that fails (running Fedora 10)

python v 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)]
numpy v 1.2.0
scipy v 0.6.0
[[ 0.  0.  0.  0.]
 [ 1.  1.  0.  2.]
 [ 0.  0.  0.  2.]
 [ 0.  0.  0.  2.]]

result=
Illegal instruction

=========
Expected results:
A machine that works (running RHEL5)

python v 2.4.3 (#1, May 24 2008, 13:57:05) 
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)]
numpy v 1.0.3
scipy v 0.5.2
[[ 0.  0.  0.  0.]
 [ 1.  1.  0.  2.]
 [ 0.  0.  0.  2.]
 [ 0.  0.  0.  2.]]

result=
[2 3]

=========
Additional info:

Fails on 1 machine  with Fedora 9 on i686 Pentium 3 (scipy v0.6)
Fails on 4 machines with Fedora 10 x86_64 (scipy v0.6)
Works on 1 machine  with Fedora 8 on i686 Pentium 4 (scipy v0.6)
Works on 6 machines with RHEL 5 x86_64 (AMD and intel, scipy v0.5.2)
Works on 3 machines with RHEL 5 i686 (scipy v0.5.2)

Comment 1 Jef Spaleta 2008-12-31 21:05:04 UTC
I poked at this a little bit.  I can reproduce it on my x86 laptop. The problem is definitely in C code associated with the compiled _ndimage.so file. So what system libraries does this compiled .so file depend on?

ldd /usr/lib/python2.5/site-packages/scipy/ndimage/_nd_image.so
	linux-gate.so.1 =>  (0x00110000)
	libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x0012e000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x0027f000)
	libc.so.6 => /lib/libc.so.6 (0x00299000)
	libdl.so.2 => /lib/libdl.so.2 (0x0040d000)
	libutil.so.1 => /lib/libutil.so.1 (0x00412000)
	libm.so.6 => /lib/libm.so.6 (0x00416000)
	/lib/ld-linux.so.2 (0x00892000)


These are all pretty mundane... no atlas are anything like that.  It depends on
libpython and a smattering of libraries in the glibc package.

Is this subtle python 2.5 api breakage?  I don't know.  rhel5 is using python2.4. I'm assuming f8 is a well.  I'll jump on the upstream bug report and try to help narrow it down.

-jef

Comment 2 Jef Spaleta 2009-01-01 00:17:01 UTC
Okay I have scratch builds of scipy v0.7b1 available in koji for F10
http://koji.fedoraproject.org/koji/taskinfo?taskID=1028262

Can you do a quick test of the packages for the arches you have available for F10.

I installed the x86 package and I no longer get the illegal instruction error.


-jef

Comment 3 vossman 2009-01-02 18:57:46 UTC
Thanks and good detective work. I tried it on 2 Fedora 10 x86_64 machines and 1 Fedora 9 i686 machine and the ndimage test worked on all 3 machines.

But I can no longer import scipy.stats, I get the error:

>>> import scipy.stats
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.5/site-packages/scipy/stats/__init__.py", line 7, in <module>
    from stats import *
  File "/usr/lib64/python2.5/site-packages/scipy/stats/stats.py", line 199, in <module>
    import scipy.linalg as linalg
  File "/usr/lib64/python2.5/site-packages/scipy/linalg/__init__.py", line 8, in <module>
    from basic import *
  File "/usr/lib64/python2.5/site-packages/scipy/linalg/basic.py", line 17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib64/python2.5/site-packages/scipy/linalg/lapack.py", line 18, in <module>
    from scipy.linalg import clapack
ImportError: /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv

Comment 4 Jef Spaleta 2009-01-02 20:55:46 UTC
Im not getting that import error on my F10 x86 system.

Did you get that scipy.stat import error on the F9 or F10 system?  The build I posted was only meant for F10.  I have no idea if it would work on F9.

I might try patching the 0.6 scipy with the ndimage src from the 0.7b1.  I'm wary about dropping in an 0.7 beta as an update...introducing a lot of new issues.

-jef

Comment 5 vossman 2009-01-02 21:20:30 UTC
I get the error on all 3 of the machines mentioned, both F10 and F9. Hmm, this is weird. Anything else I can do to test this?


stats:
-----
python v 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)]
numpy v 1.2.0
scipy v 0.7.0b1

Comment 6 Jef Spaleta 2009-01-02 21:50:55 UTC
and import scipy.stats worked for you in  scipy 0.6?

okay back to the segfault...  undefined symbol: clapack_sgesv
clapack_sgesv  should be defined as a symbol from the lapack library provided by the atlas package.  Here's the analysis:

nm -D /usr/lib/python2.5/site-packages/scipy/linalg/clapack.so |grep clapack_sgesv
         U clapack_sgesv

ldd /usr/lib/python2.5/site-packages/scipy/linalg/clapack.so 
	linux-gate.so.1 =>  (0x00110000)
	liblapack.so.3 => /usr/lib/atlas/liblapack.so.3 (0x0012a000)
	libf77blas.so.3 => /usr/lib/atlas/libf77blas.so.3 (0x00666000)
	libcblas.so.3 => /usr/lib/atlas/libcblas.so.3 (0x00682000)
	libatlas.so.3 => /usr/lib/atlas/libatlas.so.3 (0x008b5000)
	libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x006a2000)
	libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00bf7000)
	libm.so.6 => /lib/libm.so.6 (0x007f3000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0081c000)
	libc.so.6 => /lib/libc.so.6 (0x00cb1000)
	libblas.so.3 => /usr/lib/atlas/libblas.so.3 (0x00e25000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x0082a000)
	libdl.so.2 => /lib/libdl.so.2 (0x00844000)
	libutil.so.1 => /lib/libutil.so.1 (0x00849000)
	/lib/ld-linux.so.2 (0x00892000)


nm -D /usr/lib/atlas/liblapack.so.3 | grep clapack_sgesv
000cffc0 T clapack_sgesv

rpm -qf /usr/lib/atlas/liblapack.so.3 
atlas-3.6.0-15.fc10.i386


Run a similar analysis on your affected machine with scipy v0.7b1 installed.
Does the liblapack.so.3 library exist and does it provide the missing symbol?


-jef

Comment 7 vossman 2009-01-02 23:50:11 UTC
Yes, it worked on all versions. I am trying to get my program to run on F9/F10 machines. 

If I replace your clapack.so with a clapack.so that I compiled it works fine.

Analysis below with lib64 instead of lib
=========================

% nm -D /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so |grep clapack_sges
                 U clapack_sgesv

% ldd /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so
	linux-vdso.so.1 =>  (0x00007fff281fd000)
	liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x000000000032d000)
	libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x0000000000abf000)
	libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x0000000000cdc000)
	libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x0000000000ef9000)
	libpython2.5.so.1.0 => /usr/lib64/libpython2.5.so.1.0 (0x0000000046293000)
	libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x0000000001879000)
	libm.so.6 => /lib64/libm.so.6 (0x0000000001b53000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000000001dd8000)
	libc.so.6 => /lib64/libc.so.6 (0x0000000001fef000)
	libblas.so.3 => /usr/lib64/libblas.so.3 (0x0000000002361000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00000000025b9000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00000000027d5000)
	libutil.so.1 => /lib64/libutil.so.1 (0x00000000029d9000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003647400000)

% nm -D /usr/lib64/atlas/liblapack.so.3 | grep clapack_sgesv
00000000000da7cc T clapack_sgesv

% rpm -qf /usr/lib64/atlas/liblapack.so.3 
atlas-3.6.0-15.fc10.x86_64

% python -c 'import scipy.stats'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python2.5/site-packages/scipy/stats/__init__.py", line 7, in <module>
    from stats import *
  File "/usr/lib64/python2.5/site-packages/scipy/stats/stats.py", line 199, in <module>
    import scipy.linalg as linalg
  File "/usr/lib64/python2.5/site-packages/scipy/linalg/__init__.py", line 8, in <module>
    from basic import *
  File "/usr/lib64/python2.5/site-packages/scipy/linalg/basic.py", line 17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/lib64/python2.5/site-packages/scipy/linalg/lapack.py", line 18, in <module>
    from scipy.linalg import clapack
ImportError: /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so: undefined symbol: clapack_sgesv

Comment 8 Jonathan Steffan 2009-01-03 22:45:38 UTC
Downloading the build and doing the follow successfully imports for me:

$ sudo yum localinstall scipy-0.7.0-0.2.b1.fc10.x86_64.rpm
[..]
Installed:
  scipy.x86_64 0:0.7.0-0.2.b1.fc10                                              

Dependency Installed:
  atlas.x86_64 0:3.6.0-15.fc10              libgfortran.x86_64 0:4.3.2-7        
  numpy.x86_64 0:1.2.0-1.fc10               python-nose.noarch 0:0.10.3-1.fc10  
  python-setuptools.noarch 0:0.6c9-1.fc10   suitesparse.x86_64 0:3.1.0-1.fc9

$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:42:03) 
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy.stats
/usr/lib64/python2.5/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:20: DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be removed, install scikits.umfpack instead
  ' install scikits.umfpack instead', DeprecationWarning )
>>> print scipy.stats.__doc__

Statistical Functions
=====================
[...]
>>>
$ uname -a
Linux dabeatport 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
$ rpm -q python
python-2.5.2-1.fc10.x86_64

Comment 9 Jef Spaleta 2009-01-03 23:45:50 UTC
vossman,

Your clapack.so issue is a bit bizarre in that I can not get it confirmed by others.  I'm going to release scipy v0.7 beta to updates-testing for f9 and f10. But I'm still not convinced that I should push these beta as an actual update. I want this tested significantly.  

I am a little concerned about your clapack.so issue, if you are able, please can you retest this scipy v0.7 on a fresh f10 install with official fedora updates before any other local customizations are applied.  My gut tells me that you've got some local environment interactions going that we aren't going to be able to reproduce on a stock f10+updates setup. But I need you to try to confirm that.

-jef

Comment 10 Fedora Update System 2009-01-04 05:44:44 UTC
scipy-0.7.0-0.1.b1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/scipy-0.7.0-0.1.b1.fc9

Comment 11 Fedora Update System 2009-01-04 05:44:52 UTC
scipy-0.7.0-0.1.b1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/scipy-0.7.0-0.1.b1.fc10

Comment 12 vossman 2009-01-04 07:13:59 UTC
I tried this on my home machine, Core 2 Duo with F10 and I get a warning, which is what you get:

after running:
% sudo rpm -Uhv  scipy-0.7.0-0.2.b1.fc10.x86_64.rpm

% python 
>>> import scipy.stats
/usr/lib64/python2.5/site-packages/scipy/sparse/linalg/dsolve/linsolve.py:20: DeprecationWarning: scipy.sparse.linalg.dsolve.umfpack will be removed, install scikits.umfpack instead
  ' install scikits.umfpack instead', DeprecationWarning )

First, all my machines as essentially default installs of Fedora 10 and I cannot think any custom packages installed. All run the nvidia drivers from rpmfusion. some have been upgrade from previous Fedora version and one is a brand new install. I run yum update regularly. I have three fedora work machines (x86_64|f10, x86_64|f10, and i686|f9) and two fedora home machines (x86_64|f10 and i686|f8) and access to numerous other CentOS5 machines without root access. In order to test this bug, I downloaded and compiled scipy, myself. 

With your RPM on my 3 work machines I get "undefined symbol: clapack_sgesv", but when I replace the 'clapack.so' from the RPM with a 'clapack.so' from my scipy build folder (on work1) I get the 'DeprecationWarning'. On my home machine, I get the 'DeprecationWarning' from the RPM

Linux home 2.6.27.9-159.fc10.x86_64 #1 SMP Tue Dec 16 14:47:52 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Linux work1 2.6.27.7-134.fc10.x86_64 #1 SMP Mon Dec 1 22:21:35 EST 2008 x86_64 x86_64 x86_64 GNU/Linux (updated not rebooted)
Linux work2 2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18 11:58:53 EST 2008 x86_64 x86_64 x86_64 GNU/Linux (updated not rebooted)

home is a Core 2 Duo with F10
work1 is a dual-dual Xeon (4 procs total)
work2 is Core 2 Quad with F10

=====

Okay, so I tried looking closer at the ldd libraries and noticed they are different for different machines:

% for i in `ldd  /usr/lib64/python2.5/site-packages/scipy/linalg/clapack.so | cut -c2- | cut -d' ' -f3`; do md5sum $i; done

% rpm -qa | egrep -i "^(atlas|scipy|numpy|gcc|lapack)" | sort
% rpm -q python


home : "DeprecationWarning"
---
54b6ffd90f354a9a8d51514689dfb51c  /usr/lib64/atlas/liblapack.so.3
c45fd264d17b355e39f84172ee2fa505  /usr/lib64/atlas/libf77blas.so.3
532cad2d8a3ae5cffed4e9bd7ba3db70  /usr/lib64/atlas/libcblas.so.3
a5f4c5c1a93ad5b6e7a69af4b15d7948  /usr/lib64/atlas/libatlas.so.3
3853f4938c68adb673930bec1a31265e  /usr/lib64/libpython2.5.so.1.0
90d17d13bfca792e45e54287db6b06c1  /usr/lib64/libgfortran.so.3
918476aee51d425111e25f9f7cbbc2dc  /lib64/libm.so.6
be75513c367a661b1e925d3c1fb51508  /lib64/libgcc_s.so.1
523ea28facc1c27b13b62cdd6434e399  /lib64/libc.so.6
e36b35a26789539d73597f8b46dd5b07  /usr/lib64/atlas/libblas.so.3
7b8e59087c7a84f17c9861ec1a586042  /lib64/libpthread.so.0
8655decba50ae9838fdb4dca33075927  /lib64/libdl.so.2
2b9d7b735968eefd3c3b2d4d5839b94b  /lib64/libutil.so.1

atlas-3.6.0-15.fc10.x86_64
gcc-4.3.2-7.x86_64
gcc-c++-4.3.2-7.x86_64
gcc-gfortran-4.3.2-7.x86_64
gcc-objc-4.3.2-7.x86_64
numpy-1.2.0-1.fc10.x86_64
scipy-0.7.0-0.2.b1.fc10.x86_64
python-2.5.2-1.fc10.x86_64

work1 : "undefined symbol: clapack_sgesv"
-----
330ef08a9077b8db91957a620ff3c2c5  /usr/lib64/liblapack.so.3
c45fd264d17b355e39f84172ee2fa505  /usr/lib64/atlas/libf77blas.so.3
532cad2d8a3ae5cffed4e9bd7ba3db70  /usr/lib64/atlas/libcblas.so.3
a5f4c5c1a93ad5b6e7a69af4b15d7948  /usr/lib64/atlas/libatlas.so.3
a315389ec493c76e7c1db7dd2240921c  /usr/lib64/libpython2.5.so.1.0
be75ba75b0c2533717f07a80ad7c63bb  /usr/lib64/libgfortran.so.3
0e5ab77488973f46672dcd27f6af8400  /lib64/libm.so.6
46cbc417835df9237d01a547aac19a95  /lib64/libgcc_s.so.1
9eeb7be08e8723346c8ef6f35ad07629  /lib64/libc.so.6
14bbb99e812f6ccaa712d242fcc627fe  /usr/lib64/libblas.so.3
b4ff580132d8297070a9e5fb78511f1b  /lib64/libpthread.so.0
34be03195b42597b53eca3fc4086f75f  /lib64/libdl.so.2
f12b040abe394c200476f065481d5191  /lib64/libutil.so.1

atlas-3.6.0-15.fc10.x86_64
atlas-devel-3.6.0-15.fc10.x86_64
gcc-4.3.2-7.x86_64
gcc-c++-4.3.2-7.x86_64
gcc-gfortran-4.3.2-7.x86_64
gcc-objc-4.3.2-7.x86_64
gcc-objc++-4.3.2-7.x86_64
lapack-3.1.1-4.fc10.x86_64
lapack-devel-3.1.1-4.fc10.x86_64
numpy-1.2.0-1.fc10.x86_64
scipy-0.7.0-0.2.b1.fc10.x86_64
python-2.5.2-1.fc10.x86_64

work2 : "undefined symbol: clapack_sgesv"
-----
330ef08a9077b8db91957a620ff3c2c5  /usr/lib64/liblapack.so.3
c45fd264d17b355e39f84172ee2fa505  /usr/lib64/atlas/libf77blas.so.3
532cad2d8a3ae5cffed4e9bd7ba3db70  /usr/lib64/atlas/libcblas.so.3
a5f4c5c1a93ad5b6e7a69af4b15d7948  /usr/lib64/atlas/libatlas.so.3
e81f1453ef996c9c046b6867c4e5f2a3  /usr/lib64/libpython2.5.so.1.0
774bde26903521befe413d1d4932f568  /usr/lib64/libgfortran.so.3
af821bae00a369c23dac3eca23eb3632  /lib64/libm.so.6
ad6f7620b779ed6c56094d2d5283e9b2  /lib64/libgcc_s.so.1
8ff0d2c0f09a47af17dc46b725621ac2  /lib64/libc.so.6
14bbb99e812f6ccaa712d242fcc627fe  /usr/lib64/libblas.so.3
7755c1ef5a1d074002d8cfe351803715  /lib64/libpthread.so.0
5b29d7be530bd7a1f4952c46b33503f9  /lib64/libdl.so.2
e11bf9cabe1b05534cf4e3934de3ecf3  /lib64/libutil.so.1

atlas-3.6.0-15.fc10.x86_64
gcc-4.3.2-7.x86_64
gcc-c++-4.3.2-7.x86_64
gcc-gfortran-4.3.2-7.x86_64
lapack-3.1.1-4.fc10.x86_64
numpy-1.2.0-1.fc10.x86_64
scipy-0.7.0-0.2.b1.fc10.x86_64
python-2.5.2-1.fc10.x86_64

what values should I have, and how did they get different? Shouldn't they be the same for all x86_64 Fedora 10 machines?

Comment 13 Jef Spaleta 2009-01-04 21:59:46 UTC
Ah i see the problem.

atlas and lapack packages both provide the same dynamic library liblapack.so.3
.  With lapack package installed its version is found first by the linker instead of the atlas version.  Hmm, that's a little unexpected.

I can probably work around that in my scipy package, but its probably a more general problem. I need to talk with the atlas and lapack maintainers about what the duplicate library means.

stay tuned for another scipy test update.

-jef

Comment 14 Jef Spaleta 2009-01-04 22:48:12 UTC
Hmm actually... i still can not reproduce your issue.  I have lapack and atlas installed on my f10 system and the atlas libraries are still chosen.  You could still be seeing a local environment problem.

Do you have some specialized linker path setup in your shell environment which are overriding the defaults? are the variables LD_RUN_PATH or LD_LIBRARY_PATH set in your environment?

Did you edit the system linker paths in ld.so.conf or ld.so.conf.d? This could still be a system configuration issue on your machines which is affecting how the linker is operating making it choose the /usr/lib64/liblapack.so.3 over the 
/usr/lib64/atlas/liblapack.so.3 library by enforcing a different search.

-jef

Comment 15 vossman 2009-01-05 21:41:34 UTC
Yes, I have customized LD_LIBRARY_PATH, PATH, and PYTHONPATH variables. I added '/usr/lib64/atlas/' to my LD_LIBRARY_PATH and it works fine. While this is a good work-around I think you should definitely contact the the atlas and lapack maintainers about the duplicate libraries.

work1 'no warning'
------
54b6ffd90f354a9a8d51514689dfb51c  /usr/lib64/atlas/liblapack.so.3
c45fd264d17b355e39f84172ee2fa505  /usr/lib64/atlas/libf77blas.so.3
532cad2d8a3ae5cffed4e9bd7ba3db70  /usr/lib64/atlas/libcblas.so.3
a5f4c5c1a93ad5b6e7a69af4b15d7948  /usr/lib64/atlas/libatlas.so.3
a315389ec493c76e7c1db7dd2240921c  /usr/lib64/libpython2.5.so.1.0
be75ba75b0c2533717f07a80ad7c63bb  /usr/lib64/libgfortran.so.3
0e5ab77488973f46672dcd27f6af8400  /lib64/libm.so.6
46cbc417835df9237d01a547aac19a95  /lib64/libgcc_s.so.1
9eeb7be08e8723346c8ef6f35ad07629  /lib64/libc.so.6
a958814cfb895ac1118bd3698a646d25  /usr/lib64/atlas/libblas.so.3
b4ff580132d8297070a9e5fb78511f1b  /lib64/libpthread.so.0
34be03195b42597b53eca3fc4086f75f  /lib64/libdl.so.2
f12b040abe394c200476f065481d5191  /lib64/libutil.so.1

Comment 16 Jef Spaleta 2009-01-05 22:09:55 UTC
Okay, thanks for tracking it down and confirming its a linker configuration issue.

I've brought this up on the development list.  And the follow bug has been filed in response to that discussion.

https://bugzilla.redhat.com/show_bug.cgi?id=478856

You should probably add yourself to that bug report, and perhaps explain your work environment needs to the atlas maintainer in an effort to persuade him to change the library name so as to avoid run time linking confusion.  

FYI, by default with no LD_LIBRARY_PATH environment variable defined.. the atlas package adds the appropriate path definition in a file located in /etc/ld.so.conf.d/  to extend the system wide linker library search path.  As do a number of packages.

While using LD_LIBRARY_PATH care must be taken as it replaces the system wide search path constructed through /etc/ld.so.conf.d/ 

Now that this issue is known not to be scipy specific...we can get back to the original problem :->  Please comment on the scipy updates-testing in the bodhi interface as to the suitability of the scipy 0.7 beta release when you are satisfied with your testing. I'm wary of regressions.  I'm testing it on my stuff now.

-jef

Comment 17 vossman 2009-01-05 22:46:45 UTC
Scipy v0.7b passes all my tests, so I placed a comment in bodhi.

Thanks for fixing Bug 469392 as well. We wrote a python module called quietscipy to repress all those Deprecation Warnings.

Thanks for the '/etc/ld.so.conf.d/' tip I run on a number of machines without root access, so I gone to adjusting my own LD_LIBRARY_PATH. I'll probably go and clean up my machine.

Comment 18 Fedora Update System 2009-01-07 09:07:50 UTC
scipy-0.7.0-0.1.b1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update scipy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-0020

Comment 19 Fedora Update System 2009-01-07 09:32:48 UTC
scipy-0.7.0-0.1.b1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update scipy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0211

Comment 20 vossman 2009-01-21 20:09:22 UTC
I think we can close this bug. It has been working ever since the update you provided.

Comment 21 Jef Spaleta 2009-01-21 20:16:09 UTC
This still hasn't hit stable updates.  I want to keep the bug report open until it hits stable and the bug will autoclose as part of that move.  

I'm still a little gunshy about pushing a beta release to stable because of potential regressions in other scipy related areas, so the move hasn't happened yet.

-jef

Comment 22 Fedora Update System 2009-02-24 20:59:19 UTC
scipy-0.7.0-0.1.b1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2009-02-24 21:01:54 UTC
scipy-0.7.0-0.1.b1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Jeremy Sanders 2009-03-03 10:54:23 UTC
Hmmm... this update broke my working program. scipy.interpolate.interpolate.interp1d used to return an array as a result if it was passed a single parameter. Now it returns a normal number. I thought I'd add this here to let people know in case it hits someone else.