Description of problem: determinant function det() crashes octave with the following output. GNU Octave, version 3.0.3 Copyright (C) 2008 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type `warranty'. Octave was configured for "i386-redhat-linux-gnu". Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/help-wanted.html Report bugs to <bug> (but first, please read http://www.octave.org/bugs.html to learn how to write a helpful report). For information about changes from previous versions, type `news'. octave:1> A=[1, 2, 3; 3, 5, 6; 2, 3, 4] A = 1 2 3 3 5 6 2 3 4 octave:2> det(A) octave: symbol lookup error: /usr/lib/atlas/liblapack.so.3: undefined symbol: ATL_idamax Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.A=[1, 2, 3; 3, 5, 6; 2, 3, 4] 2.det(A) 3. Actual results: octave: symbol lookup error: /usr/lib/atlas/liblapack.so.3: undefined symbol: ATL_idamax Expected results: should not fail Additional info: A bug was closed on the same issue with resolution listed for version 3.0.3 but the bug still exists in this version.
Thank you for your bug report. We are sorry, but the Fedora Project is no longer releasing bug fixes or any other updates for Fedora 3. This bug will be set to CLOSED:WONTFIX to reflect this, but please reopen it if the problem persists after upgrading to the latest version of Fedora. We also need the full name and version of the package you have installed which can be provided by: rpm -qa | grep octave
The bug is in octave3.0.3 in Fedora 10
[xxxx@xxxx tmp]$ rpm -qa | grep octave octave-3.0.3-1.fc10.i386
Re-opening. The reporter must have set the Fedora version to 3 rather than 10.
(In reply to comment #0) > Steps to Reproduce: > 1.A=[1, 2, 3; 3, 5, 6; 2, 3, 4] > 2.det(A) > 3. > > Actual results: > octave: symbol lookup error: /usr/lib/atlas/liblapack.so.3: undefined symbol: > ATL_idamax > > Expected results: > should not fail I can't duplicate that, this is what I get: octave:1> A=[1, 2, 3; 3, 5, 6; 2, 3, 4] A = 1 2 3 3 5 6 2 3 4 octave:2> det(A) ans = -1.00000 This is the version I'm using: $ rpm -q octave octave-3.0.3-1.fc10.i386 I think the problem is that the shared library liblapack.so.3 is provided by several different libraries: # rpm -q --whatprovides liblapack.so.3 atlas-sse2-3.6.0-15.fc10.i386 lapack-3.1.1-4.fc10.i386 atlas-3.6.0-15.fc10.i386 Do you have lapack installed as well? If not, can you try installing it? > Additional info: A bug was closed on the same issue with resolution listed for > version 3.0.3 but the bug still exists in this version. What bug number was it?
Installation of lapack resolved the issue. lapack should be listed as a dependency for octave.
(In reply to comment #6) > Installation of lapack resolved the issue. Thanks, good to know that my suspicion was correct. > lapack should be listed as a dependency for octave. Except it's not as simple as that. The shared library dep is generated automatically based on the shared library it was originally built against, not the actual name of the package. Unfortunately as this indicates: # rpm -q --whatprovides liblapack.so.3 atlas-sse2-3.6.0-15.fc10.i386 lapack-3.1.1-4.fc10.i386 atlas-3.6.0-15.fc10.i386 the liblapack.so.3 dependency is ambiguous. What used to happen is that in the case of multiple packages providing the same shared library yum would end up choosing the package with the shortest name that matched, in this case: atlas. But in the specific case of octave this is wrong, because the shared library it built against was actually from lapack. We should probably review all these .so name provides and see what we can do to fix this. We should only use an explicit dep as a last resort, see: http://fedoraproject.org/wiki/Packaging:Guidelines#Requires
looks like atlas should consume liblapack so from lapack package.
I think this is still present in rawhide.
Atlas should provide drop-in optimised replacements for blas and lapack libraries. So octave should use blas and lapack from atlas package, if it is installed, or reference blas and lapack, if atlas is not present. I think this is how it used to be with earlier releases of Fedora (in particular, atlas package used to provide libblas, but it does not any more). Dmitri.
uname -a Linux dhcp1-96.pnq.redhat.com 2.6.31-33.fc12.x86_64 #1 SMP Thu Sep 17 15:40:43 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux rpm -qa octave octave-3.2.2-4.fc12.x86_64 I tested on present rawhide and it seems .. it is not a problem there: Just have atlas installed in my system. Initial libs loaded include atlas 2687: find library=liblapack.so.3 [0]; searching 2687: search path=/usr/lib64/octave-3.2.2 (RPATH from file octave) 2687: trying file=/usr/lib64/octave-3.2.2/liblapack.so.3 2687: search cache=/etc/ld.so.cache 2687: trying file=/usr/lib64/atlas/liblapack.so.3 and it works correctly on octave:1> A=[1, 2, 3; 3, 5, 6; 2, 3, 4] A = 1 2 3 3 5 6 2 3 4 octave:2> det(A) ans = -1.00000
Okay I missed it .. this seems to be against i686 .. I will get a system up and also try on stable F11. Thanks,
@Parminder I got F11 up and also rawhide for atlas but counldn't reproduce this bug. The latest update for atlas-sse2 in F11 seems to solve this issue. [rakesh@test-box ~]$ rpm -qa atlas-sse2 atlas-sse2-3.8.3-4.fc11.i586 Tested on F10 also [rakesh@javelin ~]$ rpm -qa octave octave-3.0.3-1.fc10.i386 [rakesh@javelin ~]$ rpm -q --whatprovides liblapack.so.3 atlas-3.6.0-15.fc10.i386 [rakesh@javelin ~]$ readelf -s /usr/lib/atlas/liblapack.so.3 | grep ATL_idamax 27: 00000000 159 FUNC GLOBAL DEFAULT UND ATL_idamax [rakesh@javelin ~]$ I am closing this for now. In case you can reproduce by uninstalling lapack and updating to latest atlas please re-open again.