[Pkg-octave-devel] Bug#514035: octave3.0: glpk cannot find the octave runtime libraries

[LUK ShunTim]

Rafael Laboissiere wrote:
> * 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
> 

Thanks very much for a clear explanation.
ST
--