Bug 147922

Summary: octave cannot find its shared libraries
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: octaveAssignee: Ivana Varekova <varekova>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-23 07:58:22 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 Michal Jaegermann 2005-02-13 00:02:13 UTC
Description of problem:

$ octave
octave: error while loading shared libraries: liboctinterp.so: cannot
open shared object file: No such file or directory

# ldd /usr/bin/octave | grep found
	liboctinterp.so => not found
	liboctave.so => not found
	libcruft.so => not found

It looks that scriplets on an update removed links from 
/usr/%{_lib}/ and nothing bothered to recreate these.

Would not be much cleaner and simpler just to drop into
/etc/ld.so.conf.d/ a file octave.conf with an expanded line

/usr/%{_lib}/octave-%{version}

and only run ldconfig in various package scripts?  That way
the problem would disappear.

Version-Release number of selected component (if applicable):
octave-2.1.57-9

Comment 1 Ivana Varekova 2005-02-14 15:47:10 UTC
Thank you for your notice.
It works for me.
Can you give me more detailed steps to reproduce your problem.
Ivana Varekova


Comment 2 Michal Jaegermann 2005-02-14 18:02:54 UTC
It surely works when these links:

/usr/lib64/libcruft.so
/usr/lib64/liboctave.so
/usr/lib64/liboctinterp.so

are present and correct.  But in an output of 'rpm -q --scripts octave'
you can read:

#
# Remove library links
# XXX Kind of unclean.
#
pushd /usr/lib64 &> /dev/null
rm -f liboctave.so
rm -f libcruft.so
rm -f liboctinterp.so
popd &> /dev/null

Indeed unclean.  It is pretty clear that if something funny
will happen during an update and/or this fragment will be executed
in a "wrong" order then these links are gone I am seeing what
I am seeing.  This had to happen during one of recent octave
updates which were here on 2005-01-13 and 2005-01-20.

That is why I suggested instead /etc/ld.so.conf.d/octave.conf,
which would be a part of 'octave' package, and paired with
ldconfig run in (un)install scripts would solve the issue in
a clean and reliable manner without a need for any such links at all.

As a matter of fact these links are a part of the package so
there seem to be hardly any need to hack them in preuninstall.  They
will be gone with a package they belong to anyway.

BTW - pushd ... popd pair in scripts is not a very good way
do to such things.  You could do (note parentheses)

( cd /usr/lib64 || exit 
rm -f liboctave.so
rm -f libcruft.so
rm -f liboctinterp.so )

instead or simply, in this case

rm -f /usr/lib64/liboctave.so
rm -f /usr/lib64/libcruft.so
rm -f /usr/lib64/liboctinterp.so

with %{_lib}, of course, instead of an explicit lib64 in an actual
package.


Comment 3 Michal Jaegermann 2005-02-16 22:36:59 UTC
After the last 'yum update octave' (well, as a part of a bigger
package) I have again:

# ldd /usr/bin/octave | grep found
	liboctinterp.so => not found
	liboctave.so => not found
	libcruft.so => not found

and

# rpm -V octave
missing     /usr/lib64/libcruft.so
missing     /usr/lib64/liboctave.so
missing     /usr/lib64/liboctinterp.so

"automagically" while before this update everything was in its
place.

It is pretty clear that rpm scripts are not doing, or not in that
right time, what is expected from these.  The package is now
at octave-2.1.57-10 level.

Comment 4 Ivana Varekova 2005-02-21 12:31:55 UTC
Thank you for your notices.
The problem was fixed. 
The fixed version will be 2.1.57-12.
If there is a problem send some message please.
Ivana Varekova


Comment 5 Michal Jaegermann 2005-02-23 02:38:23 UTC
The problem is indeed fixed in 2.1.57-12, and everything works
fine, save an obvious typo in a spec file (see bug #149420).
For now one has to install with '--nodeps' to skip the issue
but there are no problems with finding libraries once installed.