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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.