Need help with libc6 conversion and rpath
Guys,
I am having a major problem with the libc6 conversion of my Debian package of
GNU Octave.
First some background: Octave can be seen as a C++ written shell and Matlab
interpreter around a vast set of numerical routines. It is a great program,
and extremely well supported by its author, John Eaton. Octave uses GNU
readline and history for the shell, and (TeX's) kpathsea for efficient path
searching. All three libraries are provided by Octave in order to be
portable, AFAIK at least readline differs a little from the bash version.
Under libc5, I could build/install those in /usr/lib/octave/* along with
other dynamic libraries genuine to Octave [1].
Yesterday, I tried a straight rebuild of Octave on my hamm system [2] on
which I have built libc6 versions of all my other packages. The
configure[.in] of Octave sets the following on i386 linux
RLD_FLAG='-Xlinker -rpath -Xlinker $(libdir)'
This builds fine, but it plain coredumps. Now, as far as I understand it,
rpath can help with different versions of a library in different
locations. (See [3] for a fine quote by James LewisMoss on this, taken from
the debian-policy list.)
I also tried to build Octave with that RLD_FLAG unset. Of course, it now
fails to find its libraries. If I set LD_LIBRARY_PATH, it dumps core just as
the version I built yesterday did [4]. I presume that this is caused by the
presence of libc5 and libc6 libreadline and kpathsea libs. Which I cannot get
rid of for as long as there are libc5 programs that use it.
I do not know enough about dynamic linking to sort this out by myself. I am
not quite sure whether the dynamic linker could/should be able to cope with
this.
David, can you think of a solution that does not require a major change to
Octave ?
Any other things I should try? Help is truely appreciated.
Regards, Dirk
[1] edd@miles:~> ls /usr/lib/octave/*.so
/usr/lib/octave/libcruft.so /usr/lib/octave/liboctinterp.so
/usr/lib/octave/libhistory.so /usr/lib/octave/libreadline.so
/usr/lib/octave/libkpathsea.so /usr/lib/octave/libtinst.so
/usr/lib/octave/liboctave.so
[2] ldso 1.9.6-2 The Linux dynamic linker, library and utilit
libc6 2.0.5c-0.1 The GNU C library version 2 (run-time files)
gcc 2.7.2.3-3 The GNU C compiler.
libg++272 2.7.2.8-0.1 The GNU C++ libraries (libc6 version)
[3] There are occasional good uses for -rpath. Once fer-instance: Multiple
package sets use the same, but different and incompatible versions of
a library. Package set one can put it's library in
/usr/lib/package_set_1 and compile all the binaries with `-rpath
/usr/lib/package_set_1'. Package set does the sane using
/usr/lib/package_set_2. Now we can have two conflicting versions of a
library installed at once. In most cases this situation doesn't arise
because conflicting version of the same library have different .so
names, but fer-instance gtk is in the above state. No upstream .so
names, and a need for two conflicting versions to be installed.
-- From a mail of James LewisMoss to debian-policy
[4] edd@miles:~> octave
octave: error in loading shared libraries
liboctinterp.so: cannot open shared object file: No such file or directory
edd@miles:~> LD_LIBRARY_PATH=/usr/lib/octave/ octave
Segmentation fault
--
edd@debian.org http://rosebud.sps.queensu.ca/~edd PGP KeyID 1024/6D7F08DD
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: