Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 09/16/2013 11:27 AM, Michael Stahl wrote:
On 15/09/13 23:02, Andrzej Hunt wrote:
On Sat, 2013-09-14 at 08:14 +0100, Andrzej Hunt wrote:

stoc/source/javavm/javavm.cxx needs to find java which it does by
expanding URE_INTERNAL_JAVA_DIR. This seems to be set within "unorc",
which is found automatically by cppuhelper (cppuhelper/source/paths.cxx
-- getUnoIniuri()) -- this loads unorc from wherever cppuhelper library
is  found(called libuno_ccpuhlpergcc3.so -- not sure why this is the
naming scheme?).

Running LO from instdir: instdir/unxlngx6/ure/lib/unorc is used
(generated by scp2/source/ooo/ure.scp) -- this contains the expected
URE_INTERNAL_JAVA_DIR

(It seems I was mistaken on this: the instdir unorc looks like it's
copied directly from ure/source/unorc , the scp one is/was used for
installation/)

there is now some duplication there that needs to be cleaned up,
probably by removing the scp2 definition of the rc files.

There is currently three uno{rc,.ini} files:

(1) cppuhelper/source/unorc is copied to solver and used by anthing that uses solver's cppuhelper library (built-time execution of various tools; CppunitTests).

(2) ure/source/uno{rc,.ini} is included in LO installation sets (and in instdir) as the URE uno{rc,.ini}, in the URE library directory.

(3) The LO-specific uno{rc,.ini}, sitting on top of the URE one, is defined via scp2 ProfileItems and included in LO installation sets (and in instdir) in the program directory.

[...]
i'd say working on this right now is mostly a waste of time since i
already am working on removing solver; hopefully with results this week.

One random caveat that comes to mind with running tests against instdir instead of solver is that the current setup makes sure that any JRE used by the tests is the one configured --with-jdk-home (by making use of jvmfwk's "direct mode"), not one found via the jvmfwk search mechanisms. Another caveat is that should any of those tests "accidentally" make use of bootstrap{rc,.ini}s UserInstallation, we should override that to make sure those tests do not interfere with the user's configuration.

(And at least for ELF with RPATH and for Mac OS X I would like to get away from the need for any [DY]LD_LIBRARY_PATH, when executing tools at build time and when running tests. The key for that would be that /all/ executables and dynamic libraries, including build-time tools and CppunitTest dynamic libraries, are in well-known locations relative to each other, so that they can reference each other via @ORIGIN RPATHs (ELF) resp. @loader/executable_path paths (Mac OS X).)

Stephan

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.