WSTech: Writing Systems Technology (formerly known as NRSI)
Building OpenOffice 2.0.0 from source with Graphite support
NoteThese instructions are intended for software developers who want to build SIL.OpenOffice.org from scratch. If you just want to use this program, please download the prebuilt binaries from the Graphite in OpenOffice.org page. To make effective use of these instructions you should already known how to:
Before you start
The source code patch below has been extensivily tested on gcc 3.3 and gcc 3.4 copmilers and is known to work as described below. However the attempts so far to build on systems (SuSE 10.0, Fedora 4 and Ubuntu 5.10) which use gcc 4.0 as their default compiler have produced linker related problems. Installing and building with the gcc-3.4 compiler on the systems mentioned does work as advertised, so for the time being you'll need that. If you are a gcc 4.0 expert and wish to fix these problems or know how to please get in contact with me.
Please send patches or enquires to: ?subject=Graphite%20in%20OpenOffice.org%20source'>
Getting the source code
The full OpenOffice.org 2.0.0 source code is over 260MB, making it too big to mirror here, so I have provided just the patch file require to add Graphite support. Therefore the first step in building SIL.OpenOffice.org from source is to download the OpenOffice.org 2.0.0 source which is available from OpenOffice.org 2.0.0 source.
Next you will need the patch file. The tar.bz2 archive contains the patch file and the config.log generated from the configure step used to build the packaged binaries
Building OpenOffice.org 2.0.0
Conventions used in this document
When ever you see typewriter typeface that refers to input, output or file, directory name. When commands and responses are shown the will appear in this style:
user:~> command options arguments
The user:~> part is an example shell prompt and should not be typed.
Apply the Graphite patchFirst unpack the OpenOffice.org 2.0.0 source code and extract the patch file from the archive OOo_2.0_source.tar.bz2:
user:~> tar --extract --gzip --file=OOo_2.0.0_src.tar.gz user:~> tar --extract --bzip2 --file=OOo_2.0_source_patches.tar.bz2 user:~> ls OOo_2.0.0rc3_src SIL.OO2 sourceNow apply the patch with the following commands:
user:~> cd OOo_2.0.0rc3_src user:~> patch -p1 <../SIL.OO2 source/OOo_2.0.0-SIL.OOo.patch
Providing all went well you are now ready to build OpenOffice following the normal build process, which is described in detail at OpenOffice.org for Developers. A basic build process is as follows:
Configuring the OpenOffice build environment
The configure process can be used to tell the OpenOffice.org build process what dependencies to pull in from the host system and which ones to build it's self, allowing you to create a version that is distro independent or highly distro specific. It also is where you tell the build environment where to find certain dependencies which may be in non-standard locations, such as Java. For example on SuSE systems it's important to use the option --with-jdk-home=$JAVA_HOME as the automatic discovery mechanism picks the wrong location causing errors much later in the build process.
user:~> cd config_office user:~> ./configure [your options here]For example SIL's release was built with this configure command:
user:~> ./configure --enable-libart --enable-libsn --disable-mozilla --disable-odk --disable-qadevooo --enable-fontconfig --disable-gtk --disable-gnome-vfs --enable-static-gtk --disable-kde --with-system-zlib --with-system-curl --with-jdk-home=$JAVA_HOME
Bootstrapping the build environmentThe OpenOffice.org build process uses a specialised version of make called dmake and it's own build scripts to manage it's build system. This system needs to be initialised by doing:
user:~> cd .. user:~> ./bootstrap
These steps will configure and compile dmake
Setting the environmentEvery time you use the OpenOffice.org build system and start a new shell you need to set the environment variables correctly, this is done by executing:
user:~> source LinuxIntelEnv.Set.sh
Performing a full buildJust type:
This will produce an optimised release version without debugging symbols included. As OpenOffice.org is such a large project the idea is once a full build has finished you selectively rebuild the modules you want to work on with debugging turned on.
Performing a module rebuildThe procedure for rebuilding any given module is:
user:~> cd <module name> user:~> build user:~> deliverOr with debugging:
user:~> build debug=true user:~> deliverTo perform a clean rebuild before you run build first do:
user:~> rm -rf unxlngi4.pro
The deliver command copies the results of the build process into the solver, a repository of intermediate build files which all modules depend on. If you forget this step any changes will not be seen if you rebuild other modules.
Producing an installation set
If you make any changes you will need to rebuild the instsetoo_native module to have those changes included in the packages it produces.
Changes the patch introduces
The patch applies several changes a few modules in the OpenOffice.org 2.0.0 code base, namely: