Re: Need help with libc6 conversion and rpath
joost> Just to be sure: the /usr/lib/octave/* libraries were libc6
joost> compiled ones, right?
Correct.
joost> And what does "ldd /usr/lib/octave/*" show?
edd@miles:~> ldd /usr/lib/octave/*so
/usr/lib/octave/libcruft.so:
statically linked
/usr/lib/octave/libhistory.so:
statically linked
/usr/lib/octave/libkpathsea.so:
statically linked
/usr/lib/octave/liboctave.so:
statically linked
/usr/lib/octave/liboctinterp.so:
statically linked
/usr/lib/octave/libreadline.so:
statically linked
/usr/lib/octave/libtinst.so:
statically linked
joost> (do they correctly depend on libc6, i.d. are they linked with -lc)?
Yes, following help from James Troup in private email, I added explicit -lc
switches, but got the same result. Coredumps, that is.
joost> If all that is right, then I fail to see what else you could have
joost> done wrong to make the core-dump happen (in other words, I'd say
joost> it's a octave bug, triggered by libc6).
Don't think so. I suspect a bad interaction with ld.so (whom nobody told
where to get the files as -rpath has been removed).
joost> I don't really see how you mean this. What's the output of
joost>
joost> LD_LIBRARY_PATH=/usr/lib/octave/ ldd octave
That works:
edd@miles:~> LD_LIBRARY_PATH=/usr/lib/octave/ ldd /usr/bin/octave
libc.so.6 => /lib/libc.so.6 (0x4000f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
liboctinterp.so => /usr/lib/octave//liboctinterp.so (0x400ae000)
liboctave.so => /usr/lib/octave//liboctave.so (0x401f8000)
libtinst.so => /usr/lib/octave//libtinst.so (0x402c1000)
libcruft.so => /usr/lib/octave//libcruft.so (0x402e8000)
libreadline.so => /usr/lib/octave//libreadline.so (0x4040d000)
libkpathsea.so => /usr/lib/octave//libkpathsea.so (0x4042a000)
libm.so.6 => /lib/libm.so.6 (0x40436000)
libncurses.so.3.4 => /lib/libncurses.so.3.4 (0x4044f000)
libdl.so.2 => /lib/libdl.so.2 (0x40494000)
libstdc++.so.2.7.2 => /usr/lib/libstdc++.so.2.7.2 (0x40497000)
joost> Also, if the libraries are really only used by one binary on the
joost> system (as it seems with octave, but I'm not sure), I cannot see any
joost> advantage over just statically linking those libraries in the
joost> binary.
That's *very* suboptimal and too low-tech. Well, the real reason is that
Octave allows for compiling and linking custom C++ code into '.oct' files
which you can use to extend the language. That is really powerful as
interpreted .m files can be slow --- but if you have a need for speed,
rewrite in C++ and compile. Also, you can reuse code from other libraries
(which I happen to do a lot with Octave in my paid job). This makes a for a
neat numerical environment. With static libs, these little scripts become a
lot larger as all of Octave gets linked against them. Ugly.
--
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: