Bug 147922 - octave cannot find its shared libraries
octave cannot find its shared libraries
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: octave (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-12 19:02 EST by Michal Jaegermann
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-23 02:58:22 EST
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 Michal Jaegermann 2005-02-12 19:02:13 EST
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 10:47:10 EST
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 13:02:54 EST
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 17:36:59 EST
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 07:31:55 EST
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-22 21:38:23 EST
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.

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