Issue 78458 - Components run in uno exe need not find URE libs
Summary: Components run in uno exe need not find URE libs
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: 680m215
Hardware: All All
: P3 Trivial (vote)
Target Milestone: 4.x
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-06-14 13:59 UTC by Stephan Bergmann
Modified: 2017-05-20 11:31 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2007-06-14 13:59:37 UTC
ure/source/README:1.11 l. 348 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).† There are two problems:

1  At least on unxsoli4 and unxsols4, uno.bin is linked -B direct implying -z
lazyload (the default on those platforms), so that it is not guaranteed that the
URE libs are already loaded when a component needs them.

2  The new purpenvhelper public URE shared library (see issue 78143) is not
guaranteed to be loaded by uno.bin.  (It is also missing from the list of public
libraries at ure/source/README: l. 356--357.)
Comment 1 Stephan Bergmann 2007-06-14 14:00:09 UTC
Comment 2 Stephan Bergmann 2007-08-21 14:23:45 UTC
Similar to (1) above, Windows seems to ignore linking against a DLL from which
no symbol is actually referenced.
Comment 3 Martin Hollmichel 2007-12-07 13:00:36 UTC
set target to 3.x according to
Comment 4 Marcus 2017-05-20 11:31:17 UTC
Reset assigne to the default "".