Difference between revisions of "ODF Toolkit/Efforts/OOo without URE"
(URE_BIN_DIR) |
(various updates) |
||
Line 1: | Line 1: | ||
This is one part of the broader [[ODF_Toolkit/Efforts/Packaging_Modularization|Packaging Modularization]] project. The goal is to have a special OOo product (“OOo-wo-URE”) that behaves like the normal OOo product but re-uses the existing URE product. That is, installing OOo-wo-URE will require URE to be installed as a prerequisite, and will use the functionality of the installed URE instead of duplicating it as the normal OOo does. For now, OOo-wo-URE is just a special additional product, but if things work out fine, it should replace the normal OOo in the future (like for OOo 3). (See also the [http://odftoolkit.openoffice.org/servlets/ReadMsg?list=dev&msgNo=32 OOo w/o URE] and [http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=19237 OOo w/o URE] mail threads for past discussions on this topic.) | This is one part of the broader [[ODF_Toolkit/Efforts/Packaging_Modularization|Packaging Modularization]] project. The goal is to have a special OOo product (“OOo-wo-URE”) that behaves like the normal OOo product but re-uses the existing URE product. That is, installing OOo-wo-URE will require URE to be installed as a prerequisite, and will use the functionality of the installed URE instead of duplicating it as the normal OOo does. For now, OOo-wo-URE is just a special additional product, but if things work out fine, it should replace the normal OOo in the future (like for OOo 3). (See also the [http://odftoolkit.openoffice.org/servlets/ReadMsg?list=dev&msgNo=32 OOo w/o URE] and [http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=19237 OOo w/o URE] mail threads for past discussions on this topic.) | ||
− | Work is done on [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fsb71 CWS sb71], which is currently based on <code> | + | Work is done on [http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=SRC680%2Fsb71 CWS sb71], which is currently based on <code>SRC680m221</code>. Work is done in multiple steps. |
===Step 1 (<code>unxlngi6</code>, <code>unxsoli4</code>, <code>unxsols4</code>)=== | ===Step 1 (<code>unxlngi6</code>, <code>unxsoli4</code>, <code>unxsols4</code>)=== | ||
Line 19: | Line 19: | ||
♦ Executables and shared libraries in the OOo-wo-URE <code>program</code> directory need to find shared libraries in the URE <code>lib</code> directory. This has been solved by replacing the <code>LINKFLAGSRUNPATH</code> mechanism in the <code>makefile.mk</code> framework with a more flexible <code>APP</code><var>n</var><code>RPATH</code>/<code>SHL</code><var>n</var><code>RPATH</code> mechanism. It specifies individually for each executable and shared library whether it is intended for the URE <code>bin</code> directory (<code>UREBIN</code>, resulting in a <code>$ORIGIN/../lib</code> <code>RPATH</code>), the URE <code>lib</code> directory (<code>URELIB</code>, resulting in a <code>$ORIGIN</code> <code>RPATH</code>), or the OOo-wo-URE <code>program</code> directory (<code>OOO</code>, the default, resulting in a <code>$ORIGIN:$ORIGIN/../ure-link/lib</code> <code>RPATH</code>). There is outstanding [http://www.openoffice.org/issues/show_bug.cgi?id=78390 issue 78390] that <code>libstdc++.so</code> is generally missing an <code>RPATH</code> and outstanding [http://www.openoffice.org/issues/show_bug.cgi?id=78406 issue 78406] that <code>python.bin</code> is generally missing an <code>RPATH</code>. | ♦ Executables and shared libraries in the OOo-wo-URE <code>program</code> directory need to find shared libraries in the URE <code>lib</code> directory. This has been solved by replacing the <code>LINKFLAGSRUNPATH</code> mechanism in the <code>makefile.mk</code> framework with a more flexible <code>APP</code><var>n</var><code>RPATH</code>/<code>SHL</code><var>n</var><code>RPATH</code> mechanism. It specifies individually for each executable and shared library whether it is intended for the URE <code>bin</code> directory (<code>UREBIN</code>, resulting in a <code>$ORIGIN/../lib</code> <code>RPATH</code>), the URE <code>lib</code> directory (<code>URELIB</code>, resulting in a <code>$ORIGIN</code> <code>RPATH</code>), or the OOo-wo-URE <code>program</code> directory (<code>OOO</code>, the default, resulting in a <code>$ORIGIN:$ORIGIN/../ure-link/lib</code> <code>RPATH</code>). There is outstanding [http://www.openoffice.org/issues/show_bug.cgi?id=78390 issue 78390] that <code>libstdc++.so</code> is generally missing an <code>RPATH</code> and outstanding [http://www.openoffice.org/issues/show_bug.cgi?id=78406 issue 78406] that <code>python.bin</code> is generally missing an <code>RPATH</code>. | ||
− | ♦ All code executed in the OOo-wo-URE context needs certain bootstrap variables to be set (see the below discussions of <code>unorc</code> and <code>jvmfwk3rc</code>). Definitions for those variables are gathered in a new <code>fundamentalrc</code> in OOo-wo-URE at <code>opt/openoffice.org2.3/program/fundamentalrc</code>. One option could be to reference those variables from all the application-default <code>rc</code> files, but that would not work: Executables like <code>javaldx</code> and <code>uno</code> reside in the URE, they would look for <code>rc</code> files next to themselves, outside the reach of OOo-wo-URE; and OOo-wo-URE could not override the used <code>rc</code> files via <code>-env:INIFILENAME=</code>, either, as that would hide any potentially existing <code>rc</code> files in URE. The solution was to extend the variable lookup code in <code>sal/rtl/source/bootstrap.cxx</code>:1.38.80.1: After unsuccessfully checking <code>rtl_bootstrap_set</code>, command line arguments, environment variables, the application-default <code>rc</code> file, and any explicit <code>rc</code> file, if <code>$URE_BOOTSTRAP</code> expands to the URL of an <code>rc</code> file, search in that file as a fallback. <code>URE_BOOTSTRAP</code> is explicitly set to the <code>fundamentalrc</code> in the OOo-wo-URE (and normal OOo, where it is effectively ignored as there is no <code>fundamentalrc</code>) start scripts (<code>soffice</code>, <code>spadmin</code>, <code>unopkg</code>, <code>pkgchk</code>; normal OOo <code>uno</code>). | + | ♦ All code executed in the OOo-wo-URE context needs certain bootstrap variables to be set (see the below discussions of <code>unorc</code> and <code>jvmfwk3rc</code>). Definitions for those variables are gathered in a new <code>fundamentalrc</code> in OOo-wo-URE at <code>opt/openoffice.org2.3/program/fundamentalrc</code>. One option could be to reference those variables from all the application-default <code>rc</code> files, but that would not work: Executables like <code>javaldx</code> and <code>uno</code> reside in the URE, they would look for <code>rc</code> files next to themselves, outside the reach of OOo-wo-URE; and OOo-wo-URE could not override the used <code>rc</code> files via <code>-env:INIFILENAME=</code>, either, as that would hide any potentially existing <code>rc</code> files in URE. The solution was to extend the variable lookup code in <code>sal/rtl/source/bootstrap.cxx</code>:1.38.80.1: After unsuccessfully checking <code>rtl_bootstrap_set</code>, command line arguments, environment variables, the application-default <code>rc</code> file, and any explicit <code>rc</code> file, if <code>$URE_BOOTSTRAP</code> expands to the URL of an <code>rc</code> file, search in that file as a fallback. <code>URE_BOOTSTRAP</code> is explicitly set to the <code>fundamentalrc</code> in the OOo-wo-URE (and normal OOo, where it is effectively ignored as there is no <code>fundamentalrc</code>) start scripts (<code>soffice</code>, <code>spadmin</code>, <code>unopkg</code>, <code>pkgchk</code>; normal OOo <code>uno</code>). However, the way that is done (<code>URE_BOOTSTRAP=file://$sd_prog/fundamentalrc</code>) is broken, if <code>sd_prog</code> happens to contain any characters that are problematic in URLs (especially “<code>%</code>”). |
: Unsure if I understood the <code>fundamentalrc</code> concept correctly, in my naive understanding we just want to layer products on top of each other, so the introduction of something as modifiable variables (<code>UNO_TYPES=$UNO_TYPES:<bla></code>) should be sufficient. Regarding the <code>uno.exe</code>, I don't see a solution other than to provide a "new" <code>uno.exe</code> in any additional layer, if one does not want to plug-in but actually only want to provide additional services with it, the <code>unorc</code> for this <code>uno.exe</code> than references the variables defined in the UREs <code>unorc</code>. Though, this solution wouldn't be perfect or even would be unimplementable, as the order of paths in the <code>PATH</code> variable would now be important respectively one could only put one link to a <code>uno.exe</code> in the <code>/usr/bin</code> directory. -- [[User:Kr|KR]] 13:39, 14 May 2007 (CEST) | : Unsure if I understood the <code>fundamentalrc</code> concept correctly, in my naive understanding we just want to layer products on top of each other, so the introduction of something as modifiable variables (<code>UNO_TYPES=$UNO_TYPES:<bla></code>) should be sufficient. Regarding the <code>uno.exe</code>, I don't see a solution other than to provide a "new" <code>uno.exe</code> in any additional layer, if one does not want to plug-in but actually only want to provide additional services with it, the <code>unorc</code> for this <code>uno.exe</code> than references the variables defined in the UREs <code>unorc</code>. Though, this solution wouldn't be perfect or even would be unimplementable, as the order of paths in the <code>PATH</code> variable would now be important respectively one could only put one link to a <code>uno.exe</code> in the <code>/usr/bin</code> directory. -- [[User:Kr|KR]] 13:39, 14 May 2007 (CEST) | ||
Line 50: | Line 50: | ||
* Code like <code>URE_BIN_DIR=file://$sd_prog/../ure-link/bin</code> in a start script is broken, if <code>sd_prog</code> happens to contain any characters that are problematic in URLs (especially “<code>%</code>”). | * Code like <code>URE_BIN_DIR=file://$sd_prog/../ure-link/bin</code> in a start script is broken, if <code>sd_prog</code> happens to contain any characters that are problematic in URLs (especially “<code>%</code>”). | ||
The cons are: | The cons are: | ||
− | * Within the start scripts, <code>javaldx</code> is now searched for in a way that on the one hand duplicates <code>URE_BIN_DIR</code> and on the other hand may get out of sync with <code>URE_BIN_DIR</code>. | + | * Within the start scripts, <code>javaldx</code> is now searched for in a way that on the one hand duplicates <code>URE_BIN_DIR</code> and on the other hand may get out of sync with <code>URE_BIN_DIR</code>. (Searching <code>javaldx</code> in both <code>$sd_prog</code> and <code>$sd_prog/../ure-link/bin</code> can be simplified once OOo-wo-URE completely replaces the now-normal OOo.) |
♦ Until now the <code>uno</code> executable had been started from extension manager with <code>UNO_SERVICES</code> set to just the <code>services.rdb</code> in the “program directory.” It is unclear what exactly this was supposed to be good for, and has been removed for now. Similarly, until now the <code>unopkg</code> executable had bootstrapped UNO in a nonstandard way, using just the <code>types.rdb</code> and <code>services.rdb</code> in the “program directory.” Again, it is unclear what exactly this was supposed to be good for, and has been replaced with a standard UNO bootstrapping mechanism for now. | ♦ Until now the <code>uno</code> executable had been started from extension manager with <code>UNO_SERVICES</code> set to just the <code>services.rdb</code> in the “program directory.” It is unclear what exactly this was supposed to be good for, and has been removed for now. Similarly, until now the <code>unopkg</code> executable had bootstrapped UNO in a nonstandard way, using just the <code>types.rdb</code> and <code>services.rdb</code> in the “program directory.” Again, it is unclear what exactly this was supposed to be good for, and has been replaced with a standard UNO bootstrapping mechanism for now. | ||
Line 94: | Line 94: | ||
♦ Executables and shared libraries in the OOo-wo-URE <code>program</code> directory need to find shared libraries in the URE <code>bin</code> directory. This is solved by using the Windows <code>/DELAYLOAD</code> mechanism (see [http://www.openoffice.org/issues/show_bug.cgi?id=77184 issue 77184]). However, this has some implications: | ♦ Executables and shared libraries in the OOo-wo-URE <code>program</code> directory need to find shared libraries in the URE <code>bin</code> directory. This is solved by using the Windows <code>/DELAYLOAD</code> mechanism (see [http://www.openoffice.org/issues/show_bug.cgi?id=77184 issue 77184]). However, this has some implications: | ||
* It turned out <code>_RawDllMain</code> in <code>sal/osl/w32/dllentry.c</code>:1.29 does things that cannot be done in <code>DllMain</code>. This appears to be no problem in plain OOo, but caused various crashes during the build of CWS sb71 (where tools built during the build were executed during the build). This needs to be fixed (hro); for now I work around it with a <code>__try{</code>...<code>}__except(EXCEPTION_EXECUTE_HANDLER){}</code> hack in <code>_RawDllMain</code>. | * It turned out <code>_RawDllMain</code> in <code>sal/osl/w32/dllentry.c</code>:1.29 does things that cannot be done in <code>DllMain</code>. This appears to be no problem in plain OOo, but caused various crashes during the build of CWS sb71 (where tools built during the build were executed during the build). This needs to be fixed (hro); for now I work around it with a <code>__try{</code>...<code>}__except(EXCEPTION_EXECUTE_HANDLER){}</code> hack in <code>_RawDllMain</code>. | ||
− | * Similar to the symbolic <code>ure-link</code> on Unix, a plain text file <code>ure-link</code> is located in the root directory of OOo-wo-URE, containing a (relative) path to the URE installation (i.e., <code>..\URE</code>). This file is read by the delayload hook code. | + | * Similar to the symbolic <code>ure-link</code> on Unix, a plain text file <code>ure-link</code> (in what encoding?) is located in the root directory of OOo-wo-URE, containing a (relative) path to the URE installation (i.e., <code>..\URE</code>). This file is read by the delayload hook code. |
− | * For some dynamic libraries from URE using <code>/DELAYLOAD</code> does not work (see below). This can be solved by including the <code>URE/bin</code> directory in the <code>PATH</code> environment variable. This | + | * For some dynamic libraries from URE using <code>/DELAYLOAD</code> does not work (see below). This can be solved by including the <code>URE/bin</code> directory in the <code>PATH</code> environment variable. This is done in a loader around each relevant OOo-wo-URE executable (see below; the <code>ure-link</code> file is used to determine the location of the URE). (All other libraries from URE are still loaded via <code>/DELAYLOAD</code>, as it is more robust than using <code>PATH</code>, which comes last in the [http://msdn2.microsoft.com/en-us/library/ms682586.aspx dynamic-link library search order].) |
** The STLport <code>stlport_vc7145.dll</code> (resp. <code>stlport_vc71_stldebug45.dll</code>) exports various data symbols that client code imports: | ** The STLport <code>stlport_vc7145.dll</code> (resp. <code>stlport_vc71_stldebug45.dll</code>) exports various data symbols that client code imports: | ||
*** <code><iostream></code>: | *** <code><iostream></code>: | ||
Line 134: | Line 134: | ||
**** <code>forms/source/xforms/xpathlib/xpathlib.cxx</code>:1.6 | **** <code>forms/source/xforms/xpathlib/xpathlib.cxx</code>:1.6 | ||
** The linker gives a warning that it ignores <code>/DELAYLOAD</code> for <code>MSVCR71.DLL</code> (resp. <code>MSVCR71D.DLL</code>). | ** The linker gives a warning that it ignores <code>/DELAYLOAD</code> for <code>MSVCR71.DLL</code> (resp. <code>MSVCR71D.DLL</code>). | ||
+ | * <code>/DELAYLOAD</code> can cause other problems, see for example [http://blogs.msdn.com/junfeng/archive/2007/08/01/advantages-and-disadvantages-of-delay-load-loadlibrary.aspx advantages and disadvantages of delay load (LoadLibrary)]. And indeed, at least one problem with DLL deinitialization order has already been identified and fixed (see <code>sal/rtl/source/bootstrap.cxx</code>:1.38.80.2). | ||
− | ♦ | + | ♦ The <code>URE_BOOTSTRAP</code> deployment variable is set to the <code>fundamental.ini</code> in a loader around each relevant OOo-wo-URE executable (see below). |
+ | |||
+ | ♦ All relevant OOo-wo-URE executables now have a loader (<code>.exe</code>) that sets the <code>PATH</code> and <code>URE_BOOTSTRAP</code> environment variables (see above) and calls the real executable (<code>.bin</code>). | ||
+ | * <code>soffice</code> already had such a loader that is simply extended. | ||
+ | * <code>unopkg</code> is extended with such a loader (i.e., instead of <code>unopkg.com</code> calling <code>unopk.exe</code> there is now <code>unopkg.com</code> calling <code>unopkg.exe</code> calling <code>unopkg.bin</code>). | ||
+ | * Any other relevant OOo-wo-URE executables? | ||
+ | * <code>desktop</code> now provides three generic loaders (<code>cuiloader.exe</code> for CUI applications, <code>guiloader</code> for OOo GUI applications, and <code>so/guiloader.exe</code> for StarOffice GUI applications). | ||
♦ In OOo-wo-URE, the <code>URE_BIN_DIR</code> deployment variable for now is set to <code>$ORIGIN/../../URE/bin</code> (see the discussion about the missing <code>ure-link</code> above) in the <code>fundamental.ini</code>. | ♦ In OOo-wo-URE, the <code>URE_BIN_DIR</code> deployment variable for now is set to <code>$ORIGIN/../../URE/bin</code> (see the discussion about the missing <code>ure-link</code> above) in the <code>fundamental.ini</code>. | ||
Line 156: | Line 163: | ||
* In many places in OOo-wo-URE, libraries in the <code>program</code> directory now explicitly search for other libraries next to themselves. (Still work in progress to fix them all.) | * In many places in OOo-wo-URE, libraries in the <code>program</code> directory now explicitly search for other libraries next to themselves. (Still work in progress to fix them all.) | ||
* OOo-wo-URE <code>xcr</code> no longer has a load-on-call interface (unnecessarily used by <code>sb</code>): removed <code>xmlscript/dynload.hxx</code>. | * OOo-wo-URE <code>xcr</code> no longer has a load-on-call interface (unnecessarily used by <code>sb</code>): removed <code>xmlscript/dynload.hxx</code>. | ||
+ | |||
+ | ♦ Since on Mac OS X there no longer is an <code>soffice</code> start script, <code>URE_BOOTSTRAP</code> is set at the start of <code>soffice.bin</code> <code>main</code> (see <code>desktop/source/app/main.cxx</code>:1.8.20.1). How about any other start scripts? | ||
♦ Manual installation for now: | ♦ Manual installation for now: |
Revision as of 15:39, 21 August 2007
This is one part of the broader Packaging Modularization project. The goal is to have a special OOo product (“OOo-wo-URE”) that behaves like the normal OOo product but re-uses the existing URE product. That is, installing OOo-wo-URE will require URE to be installed as a prerequisite, and will use the functionality of the installed URE instead of duplicating it as the normal OOo does. For now, OOo-wo-URE is just a special additional product, but if things work out fine, it should replace the normal OOo in the future (like for OOo 3). (See also the OOo w/o URE and OOo w/o URE mail threads for past discussions on this topic.)
Work is done on CWS sb71, which is currently based on SRC680m221
. Work is done in multiple steps.
Step 1 (unxlngi6
, unxsoli4
, unxsols4
)
The first step was to create a OOo-wo-URE that can be installed manually and successfully smoketest on unxlngi6
, unxsoli4
, and unxsols4
(i.e., any old Unix). The following list gives the details of how this step was reached.
♦ Using the scp2
mechanism to undefine items of an existing product to define a new product, OOo-wo-URE has easily been set up as a small delta to normal OOo in scp2
. All items that are already available in the URE have been unset, and nothing else has been added, except for a few exceptions. This means that the resulting OOo-wo-URE installation sets are structured essentially the same as the existing normal OOo installation sets; this should definitely be revisited (when normal OOo is one day replaced by OOo-wo-URE, defining OOo-wo-URE in terms of normal OOo is no longer a good idea, anyway; but for now it greatly helps keep things in sync). The exceptions are as follows:
-
LICENSE
,THIRDPARTYLICENSEREADME.html
, andREADME
(with different contents) are available in both URE and OOo-wo-URE (where the OOo-wo-URE versions have the same content as the normal OOo versions for now). -
types.rdb
is in URE and a newly introducedoffapi.rdb
, containing the difference between normal OOotypes.rdb
and UREtypes.rdb
, in OOo-wo-URE replaces the normal OOotypes.rdb
(see below). -
services.rdb
are available in both URE and OOo-wo-URE, where the OOo-wo-UREservices.rdb
contains the difference between normal OOoservices.rdb
and UREservices.rdb
(see below). -
fundamentalrc
is new in OOo-wo-URE (it does not exist in either URE or normal OOo; see below). -
unorc
(with different contents) is available in both URE and OOo-wo-URE (where the OOo-wo-URE version also has different content from the normal OOo version, see below). -
jvmfwk3rc
has different content in normal OOo than in URE, but is nonetheless dropped from OOo-wo-URE (see below).
♦ The installed OOo-wo-URE will need to find the installed URE. At least on Solaris and Linux, URE is by default installed to /opt/openoffice.org/ure
, and OOo-wo-URE is by default installed to /opt/openoffice.org2.3
(same as normal OOo). However, these paths can be changed (at deployment time and also later on). For now, assume there is a soft link named ure-link
in the base directory of OOo-wo-URE that points to the base directory of URE, and include in scp2
such a Unixlink
(see issue 79432) that points to the default location of URE relative to the default location of OOo-wo-URE (i.e., ../../OpenOffice.org URE
for MACOSX
and ../openoffice.org/ure
for all other Unix-likes). It is still unclear whether this link would better be generated at deployment time, and how it stays in sync when moving URE and/or OOo-wo-URE around. (Maybe ure
instead of ure-link
would be a better name, thinking about the possibility to potentially move the URE installation into the OOo-wo-URE installation so that ure
would not be a soft link but a true directory.)
♦ Executables and shared libraries in the OOo-wo-URE program
directory need to find shared libraries in the URE lib
directory. This has been solved by replacing the LINKFLAGSRUNPATH
mechanism in the makefile.mk
framework with a more flexible APP
nRPATH
/SHL
nRPATH
mechanism. It specifies individually for each executable and shared library whether it is intended for the URE bin
directory (UREBIN
, resulting in a $ORIGIN/../lib
RPATH
), the URE lib
directory (URELIB
, resulting in a $ORIGIN
RPATH
), or the OOo-wo-URE program
directory (OOO
, the default, resulting in a $ORIGIN:$ORIGIN/../ure-link/lib
RPATH
). There is outstanding issue 78390 that libstdc++.so
is generally missing an RPATH
and outstanding issue 78406 that python.bin
is generally missing an RPATH
.
♦ All code executed in the OOo-wo-URE context needs certain bootstrap variables to be set (see the below discussions of unorc
and jvmfwk3rc
). Definitions for those variables are gathered in a new fundamentalrc
in OOo-wo-URE at opt/openoffice.org2.3/program/fundamentalrc
. One option could be to reference those variables from all the application-default rc
files, but that would not work: Executables like javaldx
and uno
reside in the URE, they would look for rc
files next to themselves, outside the reach of OOo-wo-URE; and OOo-wo-URE could not override the used rc
files via -env:INIFILENAME=
, either, as that would hide any potentially existing rc
files in URE. The solution was to extend the variable lookup code in sal/rtl/source/bootstrap.cxx
:1.38.80.1: After unsuccessfully checking rtl_bootstrap_set
, command line arguments, environment variables, the application-default rc
file, and any explicit rc
file, if $URE_BOOTSTRAP
expands to the URL of an rc
file, search in that file as a fallback. URE_BOOTSTRAP
is explicitly set to the fundamentalrc
in the OOo-wo-URE (and normal OOo, where it is effectively ignored as there is no fundamentalrc
) start scripts (soffice
, spadmin
, unopkg
, pkgchk
; normal OOo uno
). However, the way that is done (URE_BOOTSTRAP=file://$sd_prog/fundamentalrc
) is broken, if sd_prog
happens to contain any characters that are problematic in URLs (especially “%
”).
- Unsure if I understood the
fundamentalrc
concept correctly, in my naive understanding we just want to layer products on top of each other, so the introduction of something as modifiable variables (UNO_TYPES=$UNO_TYPES:<bla>
) should be sufficient. Regarding theuno.exe
, I don't see a solution other than to provide a "new"uno.exe
in any additional layer, if one does not want to plug-in but actually only want to provide additional services with it, theunorc
for thisuno.exe
than references the variables defined in the UREsunorc
. Though, this solution wouldn't be perfect or even would be unimplementable, as the order of paths in thePATH
variable would now be important respectively one could only put one link to auno.exe
in the/usr/bin
directory. -- KR 13:39, 14 May 2007 (CEST)
♦ Native (C++) services in the normal OOo services.rdb
are currently registered without a path, and the loader finds them next to itself. Java services in the normal OOo services.rdb
are registered with a vnd.sun.star.expand:$UNO_JAVA_COMPONENT_PATH/
prefix, and this works because regcomp
gets passed a -env:UNO_JAVA_COMPONENT_PATH
that points to the location of the services at build time. Native services (there were no Java services until now) in the URE services.rdb
are currently registered in a hacky way directly in instsetoo_native/util/makefile.mk
instead of with the general mechanisms in solenv/bin/modules/installer/servicesfile.pm
(with a vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/
prefix, using the regcomp -env
trick). For OOo-wo-URE we need all services to be registered with some vnd.sun.star.expand:
prefix (see below). regcomp
has recently been extended with -wop
, stripping the path from registered services. I improved that to -wop=prefix
, exchanging the path of registered services with the given prefix. I added build variables NATIVESERVICESURLPREFIX
(defaulting to vnd.sun.star.expand:$ORIGIN/
) and JAVASERVICESURLPREFIX
(defaulting to vnd.sun.star.expand:$UNO_JAVA_COMPONENT_PATH/
) and now always use regcomp -wop=prefix
(getting rid of the hacky build of URE services.rdb
in instsetoo_native/util/makefile.mk
). Additionally:
- The
legacy_binfilters.rdb
is built inbinfilter/util/makefile.mk
:1.9 and needs to be adapted, too. However, it is needed in a version for plain OOo (using the defaultvnd.sun.star.expand:$ORIGIN/
prefix) and in a version for OOo-wo-URE (using the OOo-wo-UREvnd.sun.star.expand:$OOO_BASE_DIR/program/
prefix). For now, two different versions are delivered tosolver
bin/legacy_binfilter.rdb
and bin/ooowoure/legacy_binfilter.rdb
. - Some components are registered via
regmergelazy
and thescp2
Regmergefile
mechanism instead. The relevant text files (desktopbe1-ucd.txt
,fps-gnome-ucd.txt
,gconfbe1-ucd.txt
,kdebe1-ucd.txt
, anducpgvfs-ucd.txt
) are now preprocessed by inserting the value ofNATIVESERVICESURLPREFIX
into the line that starts “ComponentName=
”. (Which is rather crude: It only works if there is no extra white space in that line, and only if the component is actually a native one.) - Registration of Python services (if any) in
solenv/bin/modules/installer/servicesfile.pm
has not been adapted for now.
♦ The normal OOo unorc
contains different data than the URE unorc
(at opt/openoffice.org/ure/lib/unorc
):
-
UNO_TYPES
andUNO_SERVICES
point at differentrdb
files, respectively. Clients of URE should be able to re-use the URE'sUNO_TYPES
andUNO_SERVICES
settings, and extend them with client-specific data. This has been solved by introducing the public deployment variablesURE_MORE_TYPES
andURE_MORE_SERVICES
in the URE's client interface, adding references to those variables at the end of theUNO_TYPES
andUNO_SERVICES
definitions in the UREunorc
, and settingURE_MORE_TYPES
andURE_MORE_SERVICES
as appropriate in the OOo-wo-UREfundamentalrc
. - Similarly to
UNO_TYPES
,URE_INTERNAL_JAVA_CLASSPATH
is used in the normal OOounorc
to point at various jars that contain Java UNO type representations. Clients of URE should not modify this URE-internal variable. This has been solved by introducing the public deployment variableURE_MORE_JAVA_TYPES
in the URE's client interface, settingURE_INTERNAL_JAVA_CLASSPATH
to$URE_MORE_JAVA_TYPES
in the UREunorc
, and settingURE_MORE_JAVA_TYPES
as appropriate in the OOo-wo-UREfundamentalrc
. - The normal OOo
unorc
containsUNO_SHARED_PACKAGES_CACHE
andUNO_USER_PACKAGES_CACHE
that are referenced both from otherrc
files and from macro-expansion code. Those definitions are kept in the OOo-wo-UREunorc
(for the references from otherrc
files), and are duplicated as trivial forwards in the OOo-wo-UREfundamentalrc
(for the references form macro-expansion code, which wants to read the variables from the UREunorc
and finds the definitions in thefundamentalrc
fallback). - Similarly, the normal OOo
unorc
containsPKG_SharedUnoFile
andPKG_UserUnoFile
that are used in definingUNO_TYPES
,UNO_SERVICES
, andURE_INTERNAL_JAVA_CLASSPATH
. Those definitions are kept in the OOo-wo-UREunorc
and are now referenced from the definitions ofURE_MORE_TYPES
,URE_MORE_SERVICES
, andURE_MORE_JAVA_TYPES
in the OOo-wo-UREfundamentalrc
. - The normal OOo
unorc
containsUNO_JAVA_COMPONENT_PATH
to locate Java UNO component jars (inprogram/classes
) from theservices.rdb
. In OOo-wo-URE, this has been replaced byOOO_BASE_DIR
infundamentalrc
to locate both native UNO component shared libraries (inprogram
) and Java UNO compoennt jars (inprogram/classes
) from the OOo-wo-UREservices.rdb
. (Another possible approach would be to change component loaders so that they search for component files relative to theservices.rdb
that mentions them.)
This means that OOo-wo-URE still contains a (somewhat misnamed) unorc
. This could be cleaned up.
♦ The normal OOo jvmfwk3rc
contains different data than the URE jvmfwk3rc
(at opt/openoffice.org/ure/lib/jvmfwk3rc
):
- The normal OOo has
UNO_JAVA_JFW_SHARED_DATA
andUNO_JAVA_JFW_USER_DATA
pointing atjavasettings.xml
files in the normal OOo shared and per-user configuration trees, while the URE has those variables pointing atjavasettings.xml
files in the URE-specific/etc/opt/ure
and~/.ure
directories. This means that OOo-wo-URE now also uses the URE locations—which in turn means that different installations of OOo-wo-URE share thosejavasettings.xml
files, whether that is considered good or bad. - The normal OOo sets
UNO_JAVA_JFW_CLASSPATH_URLS
to contain certain jars taken from the system where applicable (see lines 820–848 ofscp2/source/ooo/profileitem_ooo.scp
:1.44). This has been solved by introducing the public deployment variableURE_MORE_JAVA_CLASSPATH_URLS
in the URE's client interface, settingUNO_JAVA_JFW_CLASSPATH_URLS
to$URE_MORE_JAVA_CLASSPATH_URLS
in the UREjvmfwk3rc
, and settingURE_MORE_JAVA_CLASSPATH_URLS
as appropriate in the OOo-wo-UREfundamentalrc
.
♦ The javavendors.xml
(at opt/openoffice.org/ure/share/misc/javavendors.xml
, used by both URE and OOo-wo-URE, referenced by UNO_JAVA_JFW_VENDOR_SETTINGS
in jvmfwk3rc
) lists the names (without paths) of shared libraries to access various JVM implementations. Those libraries (currently just the single sunjavaplugin.so
) are located at opt/openoffice.org/ure/lib
, but searched for in a way that could break for OOo-wo-URE (it did break when OOo-wo-URE used its own jvmfwk3rc
, but that has changed in the meantime). The solution is to use complete URLs (namely vnd.sun.star.expand
URLs) in javavendors.xml
: vnd.sun.star.expand:$URE_INTERNAL_LIB_DIR/sunjavaplugin.so
. A new internal C++ helper function cppu::bootstrap_expandUri
has been added to cppuhelper
(also used in stoc/source/loader/dllcomponentloader.cxx
). Also, with this change, URE and (normal) OOo no longer need different versions of javavendors.xml
files generated in jvmfwk
. In turn, normal OOo now also needs to define URE_INTERNAL_LIB_DIR
in its unorc
(maybe another fresh variable is needed that is not URE-internal).
♦ The above change implies that build-time calls of tools like regcomp
now also need to find a definition of URE_INTERNAL_LIB_DIR
. Instead of always passing it as an -env
command line argument, a minimal unorc
/uno.ini
has been added to the build environment (delivered from cppuhelper
to the solver lib
(Unix) resp. bin
(Windows) directory; in both worlds, both unorc
and uno.ini
are delivered, which should be harmless). The unorc
only contains a definition for URE_INTERNAL_LIB_DIR
(just $ORIGIN
, as the unorc
/uno.ini
is located in the same directory as the cppuhelper
shared library on the solver). It would be nice to also include a definition for URE_INTERNAL_JAVA_DIR
(and not have to pass it via -env
in solenv/bin/modules/installer/servicesfile.pm
, for example), but that would have to be $ORIGIN/../binext
on Unix, where ext
can vary over a build's time (at Sun Hamburg for example, MWS builds by release engineering are done with ext
empty, then solver is copied so that ext
is the milestone number, and developer CWS builds spawned from that milestond also have a mileston number ext
). So I unfortunately had to leave URE_INTERNAL_JAVA_DIR
alone.
♦ The extension manager (within soffice
, as well as the standalone unopkg
and deprecated pkgchk
) spawns uno
processes. Until now it located the uno
start script in the “program directory” (opt/openoffice.org2.3/program
). To find the opt/openoffice.org/ure/bin/uno
(and have a normal OOo still working, too), the URE_BIN_DIR
bootstrap variable is introduced. At first, I set it in the OOo-wo-URE (and normal OOo) start scripts (soffice
, spadmin
, unopkg
, pkgchk
; normal OOo uno
), where URE_BIN_DIR
was also used to locate the javaldx
executable that was similarly expected in the “program directory” until now (and that made it more convenient to have URE_BIN_DIR
as an environment variable than in unorc
etc.). However, I revisited that decision and now set URE_BIN_DIR
as follows:
- In a normal OOo, it is set to
$ORIGIN
in theunorc
. - In OOo-wo-URE, it is set to
$ORIGIN/../ure-link/bin
in thefundamentalrc
.
The pros are:
- Same treatment on all platforms (on
wntmsci10
there are no start scripts at all, and onunxmacxi
at least thesoffice
start script has been removed). - Code like
URE_BIN_DIR=file://$sd_prog/../ure-link/bin
in a start script is broken, ifsd_prog
happens to contain any characters that are problematic in URLs (especially “%
”).
The cons are:
- Within the start scripts,
javaldx
is now searched for in a way that on the one hand duplicatesURE_BIN_DIR
and on the other hand may get out of sync withURE_BIN_DIR
. (Searchingjavaldx
in both$sd_prog
and$sd_prog/../ure-link/bin
can be simplified once OOo-wo-URE completely replaces the now-normal OOo.)
♦ Until now the uno
executable had been started from extension manager with UNO_SERVICES
set to just the services.rdb
in the “program directory.” It is unclear what exactly this was supposed to be good for, and has been removed for now. Similarly, until now the unopkg
executable had bootstrapped UNO in a nonstandard way, using just the types.rdb
and services.rdb
in the “program directory.” Again, it is unclear what exactly this was supposed to be good for, and has been replaced with a standard UNO bootstrapping mechanism for now.
♦ Manual installation for now: For testing purposes, I have a little shell script that uses the user install scripts from setup_native
to install URE and OOo-wo-URE into some local directory tree (the argument given to the script). This setup does not catch the fact that for now a dependency on the platform-specific package level is missing from (some core package of) the OOo-wo-URE installation set to (the single package of) the URE installation set.
rm -rf $1 $HOME/.ure mkdir $1 || exit 1 $SOLARVER/$GVERDIR/bin$UPDMINOREXT/userscripts/install \ $SOLARSRC/instsetoo_native/$GVERDIR/URE/[pr]*/install/en-US/[pR]* \ $1 || exit 1 if [ ! -d $1/opt ] ; then mkdir $1/.TMP || exit 1 mv $1/* $1/.TMP || exit 1 mkdir -p $1/opt/openoffice.org || exit 1 mv $1/.TMP $1/opt/openoffice.org/ure || exit 1 fi $SOLARVER/$GVERDIR/bin$UPDMINOREXT/userscripts/install \ $SOLARSRC/instsetoo_native/$GVERDIR/OpenOffice_woURE/[pr]*/install/en-US/[pR]* \ $1/.TMP || exit 1 if [ ! -d $1/.TMP/opt ] ; then mkdir $1/.TMP/.TMP || exit 1 mv $1/.TMP/* $1/.TMP/.TMP || exit 1 mkdir $1/.TMP/opt || exit 1 mv $1/.TMP/.TMP $1/.TMP/opt/openoffice.org2.3 || exit 1 fi mv $1/.TMP/opt/openoffice.org2.3 $1/opt || exit 1 rm -r $1/.TMP || exit 1
♦ Some parts of URE that are currently classified as private by ure/source/README:1.11
are referenced from OOo-wo-URE:
- The
jvmaccess
,jvmfwk
, and Windows-onlyuwinapi
shared libraries (referenced from various OOo-wo-URE shared libraries). - The
libxml2
shared library, the Linux compiler support libraries (libgcc_s.so.1
andlibstdc++.so.6
), and the Windows compiler support librarymsvcr71.dll
(resp.msvcr71d.dll
) have been re-classified as external, “included in the URE installation because the URE needs them and it cannot be guaranteed that they are available on a given system. Applications using the URE may need those files too, so they are made available as non-private files of the URE installation. However, in an ideal world, those files would not need to be included in the URE installation.”
♦ 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
).” This guarantee had to be extended to all the shared libraries exported from URE (public and external ones). Some OOo executables currently rely on the OOo program
directory being in the LD_LIBRARY_PATH
so that C++ UNO components loaded into such processes find the relevant libraries, see DynamicLibrarySearchPaths; this needs to be addressed (the relevant libraries are no longer in the program
directory).
Step 2 (wntmsci10
)
The second step is to adapt the OOo-wo-URE so that it can be installed manually and successfully smoketest on wntmsci10
. The following list gives the details of how this step is being approached.
♦ The installed OOo-wo-URE will need to find the installed URE. On Windows, URE is by default installed to C:\Program Files\URE
, and OOo-wo-URE is by default installed to C:\Program Files\OpenOffice.org 2.3
(same as normal OOo). However, these paths can be changed (at deployment time and also later on). For now, assume that URE is installed next to OOo-wo-URE (i.e., URE
and OpenOffice.org 2.3
are sub-directories within the same directory). (URE README
states: “On Windows, the path to the installed URE is stored in the registry under the path HKEY_CLASSES_ROOT\Software\OpenOffice.org\URE
and key Path
.” However, it is unclear whether this registry information can be made available to the items that need it—the setting of the URE_BIN_DIR
deployment variable, and the way executables and shared libraries in the OOo-wo-URE program
directory find shared libraries in the URE bin
directory.)
♦ Executables and shared libraries in the OOo-wo-URE program
directory need to find shared libraries in the URE bin
directory. This is solved by using the Windows /DELAYLOAD
mechanism (see issue 77184). However, this has some implications:
- It turned out
_RawDllMain
insal/osl/w32/dllentry.c
:1.29 does things that cannot be done inDllMain
. This appears to be no problem in plain OOo, but caused various crashes during the build of CWS sb71 (where tools built during the build were executed during the build). This needs to be fixed (hro); for now I work around it with a__try{
...}__except(EXCEPTION_EXECUTE_HANDLER){}
hack in_RawDllMain
. - Similar to the symbolic
ure-link
on Unix, a plain text fileure-link
(in what encoding?) is located in the root directory of OOo-wo-URE, containing a (relative) path to the URE installation (i.e.,..\URE
). This file is read by the delayload hook code. - For some dynamic libraries from URE using
/DELAYLOAD
does not work (see below). This can be solved by including theURE/bin
directory in thePATH
environment variable. This is done in a loader around each relevant OOo-wo-URE executable (see below; theure-link
file is used to determine the location of the URE). (All other libraries from URE are still loaded via/DELAYLOAD
, as it is more robust than usingPATH
, which comes last in the dynamic-link library search order.)- The STLport
stlport_vc7145.dll
(resp.stlport_vc71_stldebug45.dll
) exports various data symbols that client code imports:-
<iostream>
:-
autodoc/source/exes/adc_uni/makefile.mk
:1.13 -
shell/source/tools/lngconvex/makefile.mk
:1.5 -
slideshow/source/engine/smilfunctionparser.cxx
:1.6 -
svx/source/customshapes/EnhancedCustomShapeFunctionParser.cxx
:1.10 -
testshl2/inc/cppunit/result/outputter.hxx
:1.5 -
testshl2/inc/getopt.hxx
:1.9 -
testshl2/inc/versionhelper.hxx
:1.5 -
testshl2/source/getopt.cxx
:1.8 -
testshl2/source/result/outputter.cxx
:1.7 -
testshl2/source/terminate.cxx
:1.6 -
testshl2/source/testshl.cxx
:1.22 -
testshl2/source/versioner.cxx
:1.8 -
transex3/source/makefile.mk
:1.44 -
unodevtools/source/skeletonmaker/makefile.mk
:1.4 -
xmlhelp/source/com/sun/star/help/makefile.mk
:1.29
-
-
<stdexcept>
:-
boost/boost-1.30.2.patch
:1.11 -
fpicker/source/win32/filepicker/dibpreview.cxx
:1.11 -
fpicker/source/win32/filepicker/previewadapter.cxx
:1.6 -
shell/inc/internal/xml_parser.hxx
:1.6 -
shell/source/win32/simplemail/senddoc.cxx
:1.5 -
shell/source/win32/simplemail/simplemapi.cxx
:1.4 -
shell/source/win32/simplemail/simplemapi.hxx
:1.5
-
-
std::numeric_limits<double>::infinity()
:-
canvas/source/tools/canvastools.cxx
:1.12
-
-
- The libxml2
libxml2.dll
exports various data symbols that client code imports:-
xmlMalloc
,xmlFree
:-
forms/source/xforms/submission/serialization_app_xml.cxx
:1.5 -
jvmfwk/source/libxmlutil.cxx
:1.6 -
libxslt/download/libxslt-1.1.16.tar.gz
:1.1 -
unoxml/source/dom/attr.cxx
:1.6 -
xmlhelp/source/com/sun/star/help/makefile.mk
:1.29 -
xmlhelp/source/cxxhelp/provider/urlparameter.cxx
:1.40
-
-
xmlXPathNAN
:-
forms/source/xforms/xpathlib/xpathlib.cxx
:1.6
-
-
- The linker gives a warning that it ignores
/DELAYLOAD
forMSVCR71.DLL
(resp.MSVCR71D.DLL
).
- The STLport
-
/DELAYLOAD
can cause other problems, see for example advantages and disadvantages of delay load (LoadLibrary). And indeed, at least one problem with DLL deinitialization order has already been identified and fixed (seesal/rtl/source/bootstrap.cxx
:1.38.80.2).
♦ The URE_BOOTSTRAP
deployment variable is set to the fundamental.ini
in a loader around each relevant OOo-wo-URE executable (see below).
♦ All relevant OOo-wo-URE executables now have a loader (.exe
) that sets the PATH
and URE_BOOTSTRAP
environment variables (see above) and calls the real executable (.bin
).
-
soffice
already had such a loader that is simply extended. -
unopkg
is extended with such a loader (i.e., instead ofunopkg.com
callingunopk.exe
there is nowunopkg.com
callingunopkg.exe
callingunopkg.bin
). - Any other relevant OOo-wo-URE executables?
-
desktop
now provides three generic loaders (cuiloader.exe
for CUI applications,guiloader
for OOo GUI applications, andso/guiloader.exe
for StarOffice GUI applications).
♦ In OOo-wo-URE, the URE_BIN_DIR
deployment variable for now is set to $ORIGIN/../../URE/bin
(see the discussion about the missing ure-link
above) in the fundamental.ini
.
♦ TODO: solenv/inc
makefile framework used both LIBCMT
and MSVCRTLIB
for similar things. Consolidated on dropping MSVCRTLIB
and using LIBCMT
only.
♦ TODO: solenv/inc
makefile framework used both LIBXML2LIB
and XML2LIB
for similar things. Consolidated on dropping XML2LIB
and using LIBXML2LIB
only.
Step 3 (unxmacxi
)
♦ Something like RPATH
/$ORIGIN
on Mac OS X? [dyld Release Notes for Mac OS X v10.4]: “Every mach-o final linked image can contain any number of LC_LOAD_DYLIB
load commands which the path of a dylib that must be loaded. Usually, it is an absolute path. We also support the path starting with @executable_path/
which means relative to the main executable. This enables the construction of applications that could be installed anywhere. In Mac OS X 10.4, we now support LC_LOAD_DYLIB
paths that start with @loader_path/
which means relative to the image containing the LC_LOAD_DYLIB
command. This enables the construction of bundles and other ‘directory trees’ of final linked images which can be installed anywhere. Currently, ld
(1) has no options for directly embedding @loader_path
into LC_LOAD_DYLIB
load command. Instead, you must post-process your final linked images with install_name_tool
.”
♦ libsalsystools.dylib
had been missing from URE (and is still missing from ure/source/README
:1.11.6.4, but will be removed on CWS salaquatox11, anyway).
♦ The vnd.sun.star.expand:$OOO_BASE_DIR/program/
prefix in OOo-wo-ure services.rdb
does not work as the program
directory is named MacOS
instead. Fixed by adding program
as a symbolic link to MacOS
.
♦ On Mac OS X, dlopen
with a plain filename searches for that filename in the current working directory, not next to the object that called dlopen
as on Linux and Solaris. That revealed a number of places where our code calls dlopen
(via osl_loadModule
, osl::Module::Module
, osl::Module::load
, vos::OModule::OModule
, vos::OModule::load
, etc.) without an explicit path, hoping to find the library. To help fixing that, osl_loadModuleRelative
and osl::Module::loadRelative
have been added.
- In URE
cppu
, libraries with native UNO environments and bridges are now explicitly searched next tocppu
itself. - URE
reg
no longer has a load-on-call interface: removedRegistryLoader
(registry/registry.hxx
),RegistryTypeReaderLoader
(registry/reflread.hxx
), andRegistryTypeWriterLoader
(registry/reflwrit.hxx
); deprecatedsalhelper/dynload.hxx
. - In many places in OOo-wo-URE, libraries in the
program
directory now explicitly search for other libraries next to themselves. (Still work in progress to fix them all.) - OOo-wo-URE
xcr
no longer has a load-on-call interface (unnecessarily used bysb
): removedxmlscript/dynload.hxx
.
♦ Since on Mac OS X there no longer is an soffice
start script, URE_BOOTSTRAP
is set at the start of soffice.bin
main
(see desktop/source/app/main.cxx
:1.8.20.1). How about any other start scripts?
♦ Manual installation for now:
#!/bin/bash rm -rf $1 ~/.ure mkdir $1 || exit 1 cp -R \ $SOLARSRC/instsetoo_native/$GVERDIR/URE/install/en-US/URE/OpenOffice.org\ URE \ $1 || exit 1 cp -R \ $SOLARSRC/instsetoo_native/$GVERDIR/OpenOffice_woURE/install/en-US/staging/OpenOffice.org\ 2.3.app \ $1 || exit 1 chmod -R u+w $1 || exit 1 find $1/OpenOffice.org\ URE/bin -maxdepth 1 -type f \ -exec bash -c 'file "$0" | grep -w '\''Mach-O executable'\'' > /dev/null' {} \ \; \ -exec install_name_tool \ -change @executable_path/libjvmfwk.dylib.3 \ @executable_path/../lib/libjvmfwk.dylib.3 \ -change @executable_path/liblibxml2wrapper.dylib.3 \ @executable_path/../lib/liblibxml2wrapper.dylib.3 \ -change @executable_path/libreg.dylib.3 \ @executable_path/../lib/libreg.dylib.3 \ -change @executable_path/libstlport_gcc.dylib \ @executable_path/../lib/libstlport_gcc.dylib \ -change @executable_path/libuno_cppu.dylib.3 \ @executable_path/../lib/libuno_cppu.dylib.3 \ -change @executable_path/libuno_cppuhelpergcc3.dylib.3 \ @executable_path/../lib/libuno_cppuhelpergcc3.dylib.3 \ -change @executable_path/libuno_sal.dylib.3 \ @executable_path/../lib/libuno_sal.dylib.3 \ -change @executable_path/libuno_salhelpergcc3.dylib.3 \ @executable_path/../lib/libuno_salhelpergcc3.dylib.3 \ {} \; || exit 1 find $1/OpenOffice.org\ URE/lib -maxdepth 1 -type f \ -exec bash -c \ 'file "$0" | grep -w '\''Mach-O dynamically linked shared library'\'' \ > /dev/null' {} \; \ -exec install_name_tool \ -change @executable_path/libjvmaccessgcc3.dylib.3 \ @loader_path/libjvmaccessgcc3.dylib.3 \ -change @executable_path/libjvmfwk.dylib.3 @loader_path/libjvmfwk.dylib.3 \ -change @executable_path/liblibxml2wrapper.dylib.3 \ @loader_path/liblibxml2wrapper.dylib.3 \ -change @executable_path/libreg.dylib.3 @loader_path/libreg.dylib.3 \ -change @executable_path/librmcxt.dylib.3 @loader_path/librmcxt.dylib.3 \ -change @executable_path/libstlport_gcc.dylib \ @loader_path/libstlport_gcc.dylib \ -change @executable_path/libstore.dylib.3 @loader_path/libstore.dylib.3 \ -change @executable_path/libuno_cppu.dylib.3 \ @loader_path/libuno_cppu.dylib.3 \ -change @executable_path/libuno_cppuhelpergcc3.dylib.3 \ @loader_path/libuno_cppuhelpergcc3.dylib.3 \ -change @executable_path/libuno_purpenvhelpergcc3.dylib.3 \ @loader_path/libuno_purpenvhelpergcc3.dylib.3 \ -change @executable_path/libuno_sal.dylib.3 @loader_path/libuno_sal.dylib.3 \ -change @executable_path/libuno_salhelpergcc3.dylib.3 \ @loader_path/libuno_salhelpergcc3.dylib.3 \ {} \; || exit 1 find $1/OpenOffice.org\ 2.3.app/Contents/MacOS -maxdepth 1 -type f \ -exec bash -c 'file "$0" | grep -w '\''Mach-O executable'\'' > /dev/null' {} \ \; \ -exec install_name_tool \ -change @executable_path/liblibxml2wrapper.dylib.3 \ @executable_path/../ure-link/lib/liblibxml2wrapper.dylib.3 \ -change @executable_path/libstlport_gcc.dylib \ @executable_path/../ure-link/lib/libstlport_gcc.dylib \ -change @executable_path/libuno_cppu.dylib.3 \ @executable_path/../ure-link/lib/libuno_cppu.dylib.3 \ -change @executable_path/libuno_cppuhelpergcc3.dylib.3 \ @executable_path/../ure-link/lib/libuno_cppuhelpergcc3.dylib.3 \ -change @executable_path/libuno_sal.dylib.3 \ @executable_path/../ure-link/lib/libuno_sal.dylib.3 \ -change @executable_path/libuno_salhelpergcc3.dylib.3 \ @executable_path/../ure-link/lib/libuno_salhelpergcc3.dylib.3 \ {} \; || exit 1 find $1/OpenOffice.org\ 2.3.app/Contents/MacOS -maxdepth 1 -type f \ -exec bash -c \ 'file "$0" | grep -w '\''Mach-O dynamically linked shared library'\'' \ > /dev/null' {} \; \ -exec install_name_tool \ -change @executable_path/libjvmaccessgcc3.dylib.3 \ @loader_path/../ure-link/lib/libjvmaccessgcc3.dylib.3 \ -change @executable_path/libjvmfwk.dylib.3 \ @loader_path/../ure-link/lib/libjvmfwk.dylib.3 \ -change @executable_path/liblibxml2wrapper.dylib.3 \ @loader_path/../ure-link/lib/liblibxml2wrapper.dylib.3 \ -change @executable_path/libstlport_gcc.dylib \ @loader_path/../ure-link/lib/libstlport_gcc.dylib \ -change @executable_path/libuno_cppu.dylib.3 \ @loader_path/../ure-link/lib/libuno_cppu.dylib.3 \ -change @executable_path/libuno_cppuhelpergcc3.dylib.3 \ @loader_path/../ure-link/lib/libuno_cppuhelpergcc3.dylib.3 \ -change @executable_path/libuno_sal.dylib.3 \ @loader_path/../ure-link/lib/libuno_sal.dylib.3 \ -change @executable_path/libuno_salhelpergcc3.dylib.3 \ @loader_path/../ure-link/lib/libuno_salhelpergcc3.dylib.3 \ -change @executable_path/libcomphelp4gcc3.dylib \ @loader_path/libcomphelp4gcc3.dylib \ -change @executable_path/libucbhelper4gcc3.dylib \ @loader_path/libucbhelper4gcc3.dylib \ -change @executable_path/libvos3gcc3.dylib @loader_path/libvos3gcc3.dylib \ {} \; || exit 1 # change all @executable_path -> @loader_path, so that when a library is # loaded from URE/bin/uno it still finds its dependent libraries sed -i -e 's!^UserInstallation=\$SYSUSERCONFIG/OpenOffice.org/2$!UserInstallation=$ORIGIN/../USERINSTALLATION!' $1/OpenOffice.org\ 2.3.app/Contents/MacOS/bootstraprc || exit 1