[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