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

Re: 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. 

Just to be sure: the /usr/lib/octave/* libraries were libc6 compiled
ones, right? And what does "ldd /usr/lib/octave/*" show? (do they
correctly depend on libc6, i.d. are they linked with -lc)?

If all that is right, then I fail to see what else you could have
done wrong to make the core-dump happen (in other words, I'd say it's
a octave bug, triggered by libc6).

> 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.

I don't really see how you mean this. What's the output of

LD_LIBRARY_PATH=/usr/lib/octave/ ldd octave

> Which I cannot get
> rid of for as long as there are libc5 programs that use it.

How do you mean? what libc5 programmes use libc5 versions of 
/usr/lib/octave/*? It was only for octave, right?

> [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

If they are incompatible versions of the library, why don't
they have different sonames? That would solve everything too, and
be much more flexible.

Also, if the libraries are really only used by one binary on the
system (as it seems with octave, but I'm not sure), I cannot see
any advantage over just statically linking those libraries in the

joost witteveen, joostje@debian.org

My spamfilter is so good, it correctly catches 90% of incoming spam,
*including* all email from my PhD supervisor.

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: