[Libreoffice] rpath / ... for extensions (and the case of PostgreSQL-SDBC)
Lionel Elie Mamane
lionel at mamane.lu
Sun Jan 22 08:55:07 PST 2012
With respect to fdo#45090, that is the GNU/Linux dlopen() does not
find libldap50.so when loading PostgreSQL-SDBC's
"Naturally", libldap50.so is in $INSTALL_DIR/program/.
Have we already solved this problem, and if yes, how do I apply the
solution to PostgreSQL-SDBC?
As I understand the problem, in DT_R(UN)PATH, when loading
postgresql-sdbc-impl.uno.so, $ORIGIN is the directory contained that
.so file, not the directory containing soffice.bin. So in some sense,
postgresql-sdbc-impl.uno.so has the "wrong' DT_RUNPATH:
(RPATH) Library rpath: [$ORIGIN:$ORIGIN/../ure-link/lib]
(RUNPATH) Library runpath: [$ORIGIN:$ORIGIN/../ure-link/lib]
Thinking of PostgreSQL-SDBC as a bundled extension, it should be:
because it sits in $INSTALL_DIR/share/extensions/postgresql-sdbc
But if it is installed as a shared extension, then it needs to be:
because it is in $INSTALL_DIR/share/uno_packages/cache/uno_packages/FOO.tmp_/postgresql-sdbc-0.8.2.oxt/postgresql-sdbc-0.8.2/linux_x64.plt
So far, so good, we could just merge these four entries. But if it is
installed as a user extension? Then no amount of fiddling with $ORIGIN
will help, since it is in the user's home directory (and where depends
on the LibreOffice version... could be .config/libreoffice/3/... or in
.libreoffice/3/...), and there is no relationship between the
$INSTALL_DIR and that.
So, what can we do?
Either we change the soffice script to set LD_LIBRARY_PATH also on
GNU/Linux, or PostgreSQL-SDBC ships a second copy of libldap50.so.
Now that I think of it, only the copy solution will make it work with
a LibreOffice compiled with --with-openldap, since that LibreOffice
won't ship libldap50.so. But distros will hate that, so they need a
way to disable that... I'd say do it only if LibreOffice is not
configured to use its internal mozldap.
Any opinions, vetos, agreements?
More information about the LibreOffice