[Pkg-octave-devel] Bug#514035: octave3.0: glpk cannot find the octave runtime libraries
Rafael Laboissiere
rafael at debian.org
Thu Feb 5 09:50:52 UTC 2009
* LUK ShunTim <shuntim.luk at polyu.edu.hk> [2009-02-05 15:12]:
> I mean liboctinterp.so, liboctave.so, liboctave.so.
>
> $ ldd /usr/bin/octave
> linux-vdso.so.1 => (0x00007fff4ffff000)
> liboctinterp.so => /usr/lib/octave-3.0.1/liboctinterp.so
> (0x00007f6a47126000)
> liboctave.so => /usr/lib/octave-3.0.1/liboctave.so (0x00007f6a46777000)
> libcruft.so => /usr/lib/octave-3.0.1/libcruft.so (0x00007f6a46512000)
> ...
>
> which is normal but, for example,
>
> $ ldd /usr/lib/octave/3.0.1/oct/x86_64-pc-linux-gnu/__glpk__.oct
> linux-vdso.so.1 => (0x00007fff327fe000)
> libcruft.so => not found
> liboctave.so => not found
> liboctinterp.so => not found
> ...
>
> and yet it still works (now).
The rpath [1] in the octave executable /usr/bin/octave is set to be
/usr/lib/octave-X.X.X at build time, cf:
$ objdump -x /usr/bin/octave-3.0.1 | grep RPATH
RPATH /usr/lib/octave-3.0.1
so that when octave is launched, all the "private libraries" are found.
On the other hand, __glpk__.oct is a loadable module that is loaded at
runtime using the dlopen function [2] and, since octave itself have already
resolved the libcruft.so, liboctave.so, and liboctinterp.so library
locations, everything works fine.
[1] http://en.wikipedia.org/wiki/Rpath_(linking)
[2] http://en.wikipedia.org/wiki/Dynamic_loading
--
Rafael
More information about the Pkg-octave-devel
mailing list