Caolan McNamara wrote:
On Thu, 2007-05-10 at 10:52 +0200, Oliver Braun wrote:
Caolan McNamara wrote:
I dropped LD_LIBRARY_PATH in the startup script for a bit, because we
have rpath ORIGIN we don't need it in OOo itself. But the snag I ran
into is that with the current layout at least we do need it so that
third party uno components spawned by OOo which are deployed
into /uno_packages/ can link against the /path/to/ooo/program
libraries :-(
If spawned in process, I would expect those libraries to already be mapped into
memory. And for out-of-process components we could adapt the launcher to set
LD_LIBRARY_PATH appropriately.
FWIW http://dba.openoffice.org/drivers/postgresql/ is an example. Post
installation without LD_LIBRARY_PATH it won't appear in the base
downdown "connect to an existing database" list, with LD_LIBRARY_PATH it
will.
Interesting, sounds like a bug, will have a look.
As Oliver already said, in-process component libraries can expect the
necessary libraries to be already available. (<quote
"http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE";>URE
README states: “C++ UNO components run from within the uno executable
can depend on an environment in which the public C++ UNO runtime dynamic
libraries (cppu, cppuhelper, sal, salhelper, stlport) are already
available (that is, on Linux x86, Solaris x86, and Solaris SPARC, a
component dynamic library need not make sure that the UNO runtime
dynamic libraries it needs can be found on its RPATH).” The question is
whether this should also pertain to UNO components or arbitrary other
libraries started from elsewhere.</quote> I think it should at least
also pertain to OOo extensions executing within OOo.)
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
