dpkg-shlibdeps and private libraries
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).
Given this info, I would suggest _rene_ to use LD_LIBRARY_PATH to override
the directories that are looked into and be done with it, however while
discussing with him we wondered if ld.so didn't lookup in the directory
of the object being loaded as well ?
If that's the case, then I should modify dpkg-shlibdeps to also look into
the directory containing the binary that's currently analyzed...
Can anyone confirm or infirm this ?
On the other hand, maybe I should just be less picky for shared objects
without SONAME... I'm not sure about it.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: