From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030619 Description of problem: # octave octave: error while loading shared libraries: liboctinterp.so: cannot open shared object file: No such file or directory /usr/bin/octave is searching liboctinterp.so from wrong directories. Version-Release number of selected component (if applicable): octave-2.1.49-2 How reproducible: Always Steps to Reproduce: 1. # octave 2. 3. Actual Results: # octave octave: error while loading shared libraries: liboctinterp.so: cannot open shared object file: No such file or directory Expected Results: Octave should have started. Additional info: System is RH9 with updates plus some files from rawhide. # locate liboctinterp.so /usr/lib/octave-2.1.49/liboctinterp.so.2.1.49 /usr/lib/octave-2.1.49/liboctinterp.so # strace octave should many different paths, but not the correct one.
octave-2.1.49-4 will appear in rawhide soon. In the mean time, you may download them from my people.redhat.com page: http://people.redhat.com/lhh/octave-2.1.49-4.i386.rpm http://people.redhat.com/lhh/octave-2.1.49-4.src.rpm Let me know if it works for you.
$ rpm -q octave octave-2.1.49-4 $ rpm -q glibc glibc-2.3.2-27.9 $ octave octave: relocation error: /usr/lib/liboctinterp.so: symbol sys_siglist, version GLIBC_2.3.3 not defined in file libc.so.6 with link time reference $ strings /lib/libc.so.6 | grep GLIBC_2.3.3 GLIBC_2.3.3 Hmm, maybe more uptodate glibc is needed than the one from RH9?
Oddly enough, I do not see that version of glibc in Raw Hide at the moment. Anyway, all the new octave package does differently than the old one is set up symlinks in /usr/lib: /usr/lib/liboctinterp.so => /usr/lib/octave-2.1.49/liboctinterp.so.2.1.49 and the like. You can always add: /usr/lib/octave-2.1.49 to /etc/ld.so.conf (don't forget to run "ldconfig" when you're done!). Either of these should make the old package (2.1.49-2) work as well as can be (...being bleeding edge software).
Perhaps with the new /etc/ld.so.conf.d/ structure, octave can safely add %{_libdir}/octave-%{version} to a file there and avoid the silly linking - which appears to break when doing an upgrade of the octave package.