Hi Stephan,
Stephan Bergmann wrote:
[..]
- Executables and shared libraries in OOo-wo-URE find shared
libraries in URE they depend on via an RPATH (recorded in those
executables and shared libraries) that includes the link to the URE.
I don't understand what you need the symbolic link for:
exported interfaces usually reside at a fixed location (be it below
/usr for bundled or /opt for unbundled packages).
The symbolic link neatly takes care of those situations where "usually"
does not fit. (Also, it is what Sun's Linker and Libraries Guide
recommends under "Dependencies Between Unbundled Products.")
Does "unbundled" here mean "not bundled with the OS" or "not bundled with each
other" ?
For manual overrides (e.g. for debugging), use LD_LIBARRAY_PATH, which
was invented for that purpose (I consider it a bug that we still use
it in our start script).
I am not talking about one-shot manual overrides. I am talking about
scenarios where I want to have two separate installations of
OOo-wo-URE/URE pairs available over a period of time (e.g., one for
developing cross-cutting feature A and the other for developing another
cross-cutting feature B in parallel).
You can get the same thing from using an alternate root when installing the
packages.
This all boils down to the question whether it makes sense to change the prefix
of the URE to a non default location A, while choosing a different prefix B for
OOo within the very same root.
If we want to support this, we will also need to adapt the symbolic link to the
correct destination during package installation of OOo w/o URE ..
Don't get me wrong, I just try to lower the barriers for the Windows solution by
avoiding "easy to have on Unix" kind of over-engineering.
[...]
If the runtime linker was able to find libuno_sal.so, we already know
URE_BIN_DIR, don't we ? Why do we have to double that information in
the shell scripts ?
Right now, URE_BIN_DIR is convenient for not breaking the normal OOo:
desktop/source/deployment/registry/component/dp_component.cxx:1.16.10.2
calls the uno executable via "$URE_BIN_DIR/uno". If it used
"$ORIGIN/../ure-link/bin/uno" instead, we would need to introduce a
directory and symbolic link ure-link/bin -> ../program into the normal
OOo. But, yes, this decision should be re-evaluated before normal OOo
is finally replaced by OOo-wo-URE.
My idea was more to use osl_getModuleURLFromFunctionAddress in the
rtl::Bootstrap code to "calculate" the value at runtime.
Regards,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
