Difference between revisions of "ODF Toolkit/Efforts/OOo without URE"
(reclassified some URE libs from external to private) |
(URE_BIN_DIR) |
||
Line 43: | Line 43: | ||
♦ The above change implies that build-time calls of tools like <code>regcomp</code> now also need to find a definition of <code>URE_INTERNAL_LIB_DIR</code>. Instead of always passing it as an <code>-env</code> command line argument, a minimal <code>unorc</code>/<code>uno.ini</code> has been added to the build environment (delivered from <code>cppuhelper</code> to the solver <code>lib</code> (Unix) resp. <code>bin</code> (Windows) directory; in both worlds, both <code>unorc</code> and <code>uno.ini</code> are delivered, which should be harmless). The <code>unorc</code> only contains a definition for <code>URE_INTERNAL_LIB_DIR</code> (just <code>$ORIGIN</code>, as the <code>unorc</code>/<code>uno.ini</code> is located in the same directory as the <code>cppuhelper</code> shared library on the solver). It would be nice to also include a definition for <code>URE_INTERNAL_JAVA_DIR</code> (and not have to pass it via <code>-env</code> in <code>solenv/bin/modules/installer/servicesfile.pm</code>, for example), but that would have to be <code>$ORIGIN/../bin<var>ext</var></code> on Unix, where <code><var>ext</var></code> can vary over a build's time (at Sun Hamburg for example, MWS builds by release engineering are done with <code><var>ext</var></code> empty, then solver is copied so that <code><var>ext</var></code> is the milestone number, and developer CWS builds spawned from that milestond also have a mileston number <code><var>ext</var></code>). So I unfortunately had to leave <code>URE_INTERNAL_JAVA_DIR</code> alone. | ♦ The above change implies that build-time calls of tools like <code>regcomp</code> now also need to find a definition of <code>URE_INTERNAL_LIB_DIR</code>. Instead of always passing it as an <code>-env</code> command line argument, a minimal <code>unorc</code>/<code>uno.ini</code> has been added to the build environment (delivered from <code>cppuhelper</code> to the solver <code>lib</code> (Unix) resp. <code>bin</code> (Windows) directory; in both worlds, both <code>unorc</code> and <code>uno.ini</code> are delivered, which should be harmless). The <code>unorc</code> only contains a definition for <code>URE_INTERNAL_LIB_DIR</code> (just <code>$ORIGIN</code>, as the <code>unorc</code>/<code>uno.ini</code> is located in the same directory as the <code>cppuhelper</code> shared library on the solver). It would be nice to also include a definition for <code>URE_INTERNAL_JAVA_DIR</code> (and not have to pass it via <code>-env</code> in <code>solenv/bin/modules/installer/servicesfile.pm</code>, for example), but that would have to be <code>$ORIGIN/../bin<var>ext</var></code> on Unix, where <code><var>ext</var></code> can vary over a build's time (at Sun Hamburg for example, MWS builds by release engineering are done with <code><var>ext</var></code> empty, then solver is copied so that <code><var>ext</var></code> is the milestone number, and developer CWS builds spawned from that milestond also have a mileston number <code><var>ext</var></code>). So I unfortunately had to leave <code>URE_INTERNAL_JAVA_DIR</code> alone. | ||
− | ♦ The extension manager (within <code>soffice</code>, as well as the standalone <code>unopkg</code> and deprecated <code>pkgchk</code>) spawns <code>uno</code> processes. Until now it located the <code>uno</code> start script in the “program directory” (<code>opt/openoffice.org2.3/program</code>). To find the <code>opt/openoffice.org/ure/bin/uno</code> (and have a normal OOo still working, too), the <code>URE_BIN_DIR</code> bootstrap variable is introduced. | + | ♦ The extension manager (within <code>soffice</code>, as well as the standalone <code>unopkg</code> and deprecated <code>pkgchk</code>) spawns <code>uno</code> processes. Until now it located the <code>uno</code> start script in the “program directory” (<code>opt/openoffice.org2.3/program</code>). To find the <code>opt/openoffice.org/ure/bin/uno</code> (and have a normal OOo still working, too), the <code>URE_BIN_DIR</code> bootstrap variable is introduced. At first, I set it in the OOo-wo-URE (and normal OOo) start scripts (<code>soffice</code>, <code>spadmin</code>, <code>unopkg</code>, <code>pkgchk</code>; normal OOo <code>uno</code>), where <code>URE_BIN_DIR</code> was also used to locate the <code>javaldx</code> executable that was similarly expected in the “program directory” until now (and that made it more convenient to have <code>URE_BIN_DIR</code> as an environment variable than in <code>unorc</code> etc.). However, I revisited that decision and now set <code>URE_BIN_DIR</code> as follows: |
+ | * In a normal OOo, it is set to <code>$ORIGIN</code> in the <code>unorc</code>. | ||
+ | * In OOo-wo-URE, it is set to <code>$ORIGIN/../ure-link/bin</code> in the <code>fundamentalrc</code>. | ||
+ | The pros are: | ||
+ | * Same treatment on all platforms (on <code>wntmsci10</code> there are no start scripts at all, and on <code>unxmacxi</code> at least the <code>soffice</code> start script has been removed). | ||
+ | * 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: | ||
+ | * 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>. | ||
♦ 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 130: | Line 137: | ||
♦ A place is needed where the <code>URE_BOOTSTRAP</code> deployment variable is set to the <code>fundamental.ini</code> in the OOo-wo-URE. For now, I work around this by manually setting the environment variable to the <code>file:</code> URL of the <code>fundamental.ini</code>. | ♦ A place is needed where the <code>URE_BOOTSTRAP</code> deployment variable is set to the <code>fundamental.ini</code> in the OOo-wo-URE. For now, I work around this by manually setting the environment variable to the <code>file:</code> URL of 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>. |
− | + | ||
− | + | ||
♦ '''TODO:''' <code>solenv/inc</code> makefile framework used both <code>LIBCMT</code> and <code>MSVCRTLIB</code> for similar things. Consolidated on dropping <code>MSVCRTLIB</code> and using <code>LIBCMT</code> only. | ♦ '''TODO:''' <code>solenv/inc</code> makefile framework used both <code>LIBCMT</code> and <code>MSVCRTLIB</code> for similar things. Consolidated on dropping <code>MSVCRTLIB</code> and using <code>LIBCMT</code> only. |
Revision as of 09:21, 20 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 SRC680m217
. 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
).
- 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
.
♦ 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
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 will need to be done in a loader around each OOo-wo-URE executable (for now, I extend thePATH
manually). (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
♦ A place is needed where the URE_BOOTSTRAP
deployment variable is set to the fundamental.ini
in the OOo-wo-URE. For now, I work around this by manually setting the environment variable to the file:
URL of the fundamental.ini
.
♦ 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
.
♦ 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