ODF Toolkit/Efforts/OOo without URE

From OpenOffice.org Wiki

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 was done on CWS sb71 and CWS sb80. Work was 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, and README (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 introduced offapi.rdb, containing the difference between normal OOo types.rdb and URE types.rdb, in OOo-wo-URE replaces the normal OOo types.rdb (see below).
services.rdb are available in both URE and OOo-wo-URE, where the OOo-wo-URE services.rdb contains the difference between normal OOo services.rdb and URE services.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 APPnRPATH/SHLnRPATH 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 (internal) URL of an rc file, search in that file as a fallback. URE_BOOTSTRAP is explicitly set to the fundamentalrc at the beginning of each relevant OOo-wo-URE (and normal OOo, where it is effectively ignored as there is no fundamentalrc) application (tools::extendApplicationEnvironment).

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 the uno.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, the unorc for this uno.exe than references the variables defined in the UREs unorc. Though, this solution wouldn't be perfect or even would be unimplementable, as the order of paths in the PATH variable would now be important respectively one could only put one link to a uno.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 in binfilter/util/makefile.mk:1.9 and needs to be adapted, too. However, it is needed in a version for plain OOo (using the default vnd.sun.star.expand:$ORIGIN/ prefix) and in a version for OOo-wo-URE (using the OOo-wo-URE vnd.sun.star.expand:$OOO_BASE_DIR/program/ prefix). For now, two different versions are delivered to solver bin/legacy_binfilter.rdb and bin/ooowoure/legacy_binfilter.rdb. As OOO_BASE_DIR is also available in plain OOo since CWS sb80, this is changed back to just one version of legacy_binfilter.rdb in CWS sb83.
Some components are registered via regmergelazy and the scp2 Regmergefile mechanism instead. The relevant text files (desktopbe1-ucd.txt, fps-gnome-ucd.txt, gconfbe1-ucd.txt, kdebe1-ucd.txt, and ucpgvfs-ucd.txt) are now preprocessed by inserting the value of NATIVESERVICESURLPREFIX 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 and UNO_SERVICES point at different rdb files, respectively. Clients of URE should be able to re-use the URE's UNO_TYPES and UNO_SERVICES settings, and extend them with client-specific data. This has been solved by introducing the public deployment variables URE_MORE_TYPES and URE_MORE_SERVICES in the URE's client interface, adding references to those variables at the end of the UNO_TYPES and UNO_SERVICES definitions in the URE unorc, and setting URE_MORE_TYPES and URE_MORE_SERVICES as appropriate in the OOo-wo-URE fundamentalrc.
Similarly to UNO_TYPES, URE_INTERNAL_JAVA_CLASSPATH is used in the normal OOo unorc 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 variable URE_MORE_JAVA_TYPES in the URE's client interface, setting URE_INTERNAL_JAVA_CLASSPATH to $URE_MORE_JAVA_TYPES in the URE unorc, and setting URE_MORE_JAVA_TYPES as appropriate in the OOo-wo-URE fundamentalrc.
The normal OOo unorc contains UNO_SHARED_PACKAGES_CACHE and UNO_USER_PACKAGES_CACHE that are referenced both from other rc files and from macro-expansion code. Those definitions are kept in the OOo-wo-URE unorc (for the references from other rc files), and are duplicated as trivial forwards in the OOo-wo-URE fundamentalrc (for the references form macro-expansion code, which wants to read the variables from the URE unorc and finds the definitions in the fundamentalrc fallback).
Similarly, the normal OOo unorc contains PKG_SharedUnoFile and PKG_UserUnoFile that are used in defining UNO_TYPES, UNO_SERVICES, and URE_INTERNAL_JAVA_CLASSPATH. Those definitions are kept in the OOo-wo-URE unorc and are now referenced from the definitions of URE_MORE_TYPES, URE_MORE_SERVICES, and URE_MORE_JAVA_TYPES in the OOo-wo-URE fundamentalrc.
The normal OOo unorc contains UNO_JAVA_COMPONENT_PATH to locate Java UNO component jars (in program/classes) from the services.rdb. In OOo-wo-URE, this has been replaced by OOO_BASE_DIR in fundamentalrc to locate both native UNO component shared libraries (in program) and Java UNO compoennt jars (in program/classes) from the OOo-wo-URE services.rdb. (Another possible approach would be to change component loaders so that they search for component files relative to the services.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 and UNO_JAVA_JFW_USER_DATA pointing at javasettings.xml files in the normal OOo shared and per-user configuration trees, while the URE has those variables pointing at javasettings.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 those javasettings.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 of scp2/source/ooo/profileitem_ooo.scp:1.44). This has been solved by introducing the public deployment variable URE_MORE_JAVA_CLASSPATH_URLS in the URE's client interface, setting UNO_JAVA_JFW_CLASSPATH_URLS to $URE_MORE_JAVA_CLASSPATH_URLS in the URE jvmfwk3rc, and setting URE_MORE_JAVA_CLASSPATH_URLS as appropriate in the OOo-wo-URE fundamentalrc.

♦ 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 the unorc.
In OOo-wo-URE, it is set to $ORIGIN/../ure-link/bin in the fundamentalrc.

The pros are:

Same treatment on all platforms (on wntmsci10 there are no start scripts at all, and on unxmacxi at least the soffice start script has been removed).
Code like URE_BIN_DIR=file://$sd_prog/../ure-link/bin in a start script is broken, if sd_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 duplicates URE_BIN_DIR and on the other hand may get out of sync with URE_BIN_DIR. (Searching javaldx 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-only uwinapi shared libraries (referenced from various OOo-wo-URE shared libraries).
The libxml2 shared library, the Linux compiler support libraries (libgcc_s.so.1 and libstdc++.so.6), and the Windows compiler support library msvcr71.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).

♦ Issue 82422 revealed two problems:

connectivity/source/drivers/hsqldb/HDriver.cxx:1.24 uses vnd.sun.star.expand URLs to address jars in the program/classes directory that are resolved wrongly in OOo-wo-URE. Fixed by using $OOO_BASE_DIR in those URLs and setting OOO_BASE_DIR in plain OOo unorc.
program/classes/sdbc_hsqldb.jar is not run in the Java UNO environment but references jurt.jar (com.sun.star.lib.util.NativeLibraryLoader) on its META-INF/MANIFEST.MF Class-Path. For now, fixed by also adding ../../ure-link/share/java/jurt.jar to the sdbc_hsqldb.jar Class-Path. To be cleaned up.

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 in sal/osl/w32/dllentry.c:1.29 does things that cannot be done in DllMain. 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 file ure-link is located in the root directory of OOo-wo-URE, containing a (relative) path to the URE installation (i.e., ..\URE), interpreted in the current Windows ANSI code page. 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 the URE/bin directory in the PATH environment variable. This is done in a loader around each relevant OOo-wo-URE executable (see below; the ure-link file is used to determine the location of the URE). (All other libraries from URE were initially still loaded via /DELAYLOAD, as it is more robust than using PATH, which comes last in the dynamic-link library search order, but see below.)
- 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 for MSVCR71.DLL (resp. MSVCR71D.DLL).
/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 (see sal/rtl/source/bootstrap.cxx:1.38.80.2). And finally, another problem related to /DELAYLOAD deinitialization order mangling has occurred (issue 82391) which I took as the sure sign that more problems of this kind will be lurking in the code and I reverted the delay loading of all DLLs (except one) again (which works due to the PATH fixup, see above). uwinapi.dll still needs to be delay loaded, as it is needed by soffice.exe (which does the PATH fixup).

♦ All relevant OOo-wo-URE executables now have a loader (.exe) that sets the PATH environment variable (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 of unopkg.com calling unopk.exe there is now unopkg.com calling unopkg.exe calling unopkg.bin).
testtool is extended with such a loader (i.e., the former testtool.exe is renamed to testtool.bin, called from the new testtool.exe loader).
Any other relevant OOo-wo-URE executables?
desktop now provides three generic loaders (cuiloader.exe for CUI applications, guiloader for OOo GUI applications, and so/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. This is fixed to ${.link:$ORIGIN/../ure-link}/bin in CWS sb83.

♦ 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 to cppu itself.
URE reg no longer has a load-on-call interface: removed RegistryLoader (registry/registry.hxx), RegistryTypeReaderLoader (registry/reflread.hxx), and RegistryTypeWriterLoader (registry/reflwrit.hxx); deprecated salhelper/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 by sb): removed xmlscript/dynload.hxx.

♦ 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-aqua/2$!UserInstallation=$ORIGIN/../USERINSTALLATION!' $1/OpenOffice.org\ 2.3.app/Contents/MacOS/bootstraprc || exit 1

Did you know that the OpenOffice.org Wiki has a WYSIWYG editor? See Help:FCKeditor

ODF Toolkit/Efforts/OOo without URE

From OpenOffice.org Wiki

Step 1 (`unxlngi6`, `unxsoli4`, `unxsols4`)

Step 2 (`wntmsci10`)

Step 3 (`unxmacxi`)

Views

Personal tools

Navigation

Create a book

Search

Toolbox

Did you know that the OpenOffice.org Wiki has a WYSIWYG editor? See Help:FCKeditor

ODF Toolkit/Efforts/OOo without URE

From OpenOffice.org Wiki

Step 1 (unxlngi6, unxsoli4, unxsols4)

Step 2 (wntmsci10)

Step 3 (unxmacxi)

Views

Personal tools

Navigation

Create a book

Search

Toolbox

Step 1 (`unxlngi6`, `unxsoli4`, `unxsols4`)

Step 2 (`wntmsci10`)

Step 3 (`unxmacxi`)