Bug 147922
Summary: | octave cannot find its shared libraries | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | octave | Assignee: | 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
Thank you for your notice. It works for me. Can you give me more detailed steps to reproduce your problem. Ivana Varekova 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. 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. 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 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. |