On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
