On Sun, Jan 22, 2012 at 10:03:24PM +0100, Fridrich Strba wrote: > I would guess that maybe there would be a way to generally ask the > extension manager to look for dependent libraries of the extensions in > other place then URE/lib only.
LD_LIBRARY_PATH envvar? With GNU ld, it is the only one I see. MacOS X has "@executable_path" which is *exactly* what we want in this situation: It is replaced by the path to the directory containing the *main* executable, not the path to the shared library; from reading the manpage, GNU ld-linux has only $ORIGIN, which is the path to the shared library (that is called @loader_path on MacOS X). > I really don't like copying over libraries like this. OTOH, even if we find a good way to handle "library load path" issue, it still does not solve the problem of how the .oxt will work with a LibreOffice compiled with --with-openldap, such as e.g. Debian's one. > On 22/01/12 19:12, Lionel Elie Mamane wrote: >> On Sun, Jan 22, 2012 at 05:55:07PM +0100, Lionel Elie Mamane wrote: >>> With respect to fdo#45090, that is the GNU/Linux dlopen() does not >>> find libldap50.so when loading PostgreSQL-SDBC's >>> postgresql-sdbc-impl.uno.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. >> I'm thinking of something along the lines of the attached patch. -- Lionel _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
