This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 491217 - shared library liblapack.so.3 dependency is ambiguous
shared library liblapack.so.3 dependency is ambiguous
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: octave (Show other bugs)
rawhide
i686 Linux
low Severity high
: ---
: ---
Assigned To: Rakesh Pandit
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 513381
  Show dependency treegraph
 
Reported: 2009-03-19 17:24 EDT by Parminder Lehal
Modified: 2009-09-24 03:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-24 03:03:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Parminder Lehal 2009-03-19 17:24:45 EDT
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@octave.org> (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.
Comment 1 John Poelstra 2009-04-17 19:55:57 EDT
    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
Comment 2 Parminder Lehal 2009-04-17 20:31:33 EDT
The bug is in octave3.0.3  in Fedora 10
Comment 3 Parminder Lehal 2009-04-17 20:35:56 EDT
[xxxx@xxxx tmp]$ rpm -qa | grep octave  
octave-3.0.3-1.fc10.i386
Comment 4 Alex Lancaster 2009-04-17 21:23:57 EDT
Re-opening.  The reporter must have set the Fedora version to 3 rather than 10.
Comment 5 Alex Lancaster 2009-04-17 21:34:48 EDT
(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?
Comment 6 Parminder Lehal 2009-04-18 16:56:07 EDT
Installation of lapack resolved the issue. lapack should be listed as a dependency for octave.
Comment 7 Alex Lancaster 2009-04-18 20:53:34 EDT
(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
Comment 8 Rakesh Pandit 2009-05-24 06:22:48 EDT
looks like atlas should consume liblapack so from lapack package.
Comment 9 Alex Lancaster 2009-07-24 19:52:24 EDT
I think this is still present in rawhide.
Comment 10 Dmitri A. Sergatskov 2009-07-24 22:33:04 EDT
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.
Comment 11 Rakesh Pandit 2009-09-21 07:27:16 EDT
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
Comment 12 Rakesh Pandit 2009-09-21 07:30:32 EDT
Okay I missed it .. this seems to be against i686 .. I will get a system up and also try on stable F11.

Thanks,
Comment 13 Rakesh Pandit 2009-09-24 03:03:09 EDT
@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.

Note You need to log in before you can comment on or make changes to this bug.