Re: dpkg-shlibdeps and private libraries
On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog <hertzog@debian.org> wrote:
> Hello,
>
> _rene_ reported me a failure with openoffice and the new dpkg-shlibdeps.
>
> ----
> Scanning debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so
> (for Depends field)
> dpkg-shlibdeps: failure: couldn't find library libsw680lp.so (note: only packages with 'shlibs' files are looked into).
> ----
>
> The problem is that libswui680lp.so has libsw680lp.so in NEEDED and thus
> dpkg-shlibdeps will try to find that library. I made it a failure when I'm
> not able to find the library as dpkg-shlibdeps is supposed to behave like
> ld.so and try to use the same mechanism to find out where the lib is.
>
> libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment
> variable apparently defined by the openoffice startup script/program.
> This variable is not set a build time (and the code wasn't expecting
> variables at that place anyway).
$ORIGIN in rpath is not an environment variable. It is used to have
directories relative to the current file in the rpath.
Typical use is something like $ORIGIN/../lib for software coming in a
$DESTDIR/bin/ directory when the libraries are in $DESTDIR/lib/. It makes
software work wherever they are installed to.
$ORIGIN alone just tells the dynamic loader to also look in the directory
where the library/binary is for other libraries. That is, if a library in
/usr/lib/foo has a $ORIGIN rpath, ld.so will also look into /usr/lib/foo
for whatever this library needs.
Now, you may think such a thing would be useless, except that if you already
get your /usr/lib/foo/libfoo.so from an rpath (i.e. a binary linked to
libfoo.so having /usr/lib/foo in its rpath), this rpath is not used for
libfoo.so's dependencies.
Mike
Reply to: