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

Re: Need help with libc6 conversion and rpath

  joost>  Just to be sure: the /usr/lib/octave/* libraries were libc6
  joost> compiled ones, right? 


  joost> And what does "ldd /usr/lib/octave/*" show?  

edd@miles:~> ldd /usr/lib/octave/*so
        statically linked
        statically linked
        statically linked
        statically linked
        statically linked
        statically linked
        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> 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: