[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Need help with libc6 conversion and rpath


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

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

[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         The GNU C compiler.
    libg++272    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: