Building OpenOffice.org 1.1.x under Windows with tcsh
Beware! The build instructions for OpenOffice.org 2.x are different!
The Cygwin tcsh environment is new (from December 2003), and can be used starting with cws_srx644_ooo20030412.
This document describes the requirements and actions that you need to build OpenOffice.org on Windows using Cygwin shell.
Commands you have to type on the keyboard follow this syntax throughout this document:
In this example, the script
configure is executed
in the directory
$SRC_ROOTwill denote the directory in which the source code of OpenOffice.org is stored.
Basically, there is the choice to build OpenOffice.org from two different branches: a stable branch, which results in the release version, or a less stable developer branch (latest release see here). Links to the different sources are given in the document.
Table of Contents
- Build Requirements
- Build Instructions
- Instructions to Build an Installation Set
- Building Localised Versions of OpenOffice.org
This section is meant as a reminder or checklist for those who have some experience in building OpenOffice.org. Everybody else should jump to the Build Requirements section.
Even experienced builders are well advised to check the release notes at http://download.openoffice.org/index.html and the section Build Requirements in this document to inform yourself about changes since the previous releases.
Detailed step-by-step build descriptions are given from the next section on.
You can perform a full build, or you can build an individual project using a prebuilt version.
To perform a full build, you need to follow these steps:
- Get the source code, either from the download webpage (http://download.openoffice.org/index.html) or alternatively via a check-out from the cvs tree against a release tag, e.g. OpenOffice_1_1_4.
- Run the
configurescript to check all requirements and to create the script
- Run the
winenv.setscript to set all environment variables.
Please see the last screen from the configure script for more specific information on setting up for your platform.
- Create the build tools using
- Build typing
build --allin the
deliverin the individual modules.
You can use a prebuilt version to build an individual project. Having a prebuilt version is necessary because the individual project you want to build could depend on other projects. A project builds a particular component of OpenOffice.org. For example, the Word Processing project builds the Word Processing application. To build an individual project, you must follow these steps:
- Download the appropriate solver tarballs from the download webpage
e.g., for 643B the solver tarball
643 is a very old release. Please use the latest version.
- Check out the modules for the project that you want to build from the
OpenOffice.org cvs tree. If your project uses the resources module,
res, check out this module also. You can, of course, also download the entire source from the download webpage (http://download.openoffice.org/index.html). However, it is not possible to download individual modules there.
- Check out the module
config_office. This is always necessary to create the build environment.
- Also check out the modules
dmake, external, sal, solenv, soltools, vos, tools, rsc and xml2cmp. These are required by
- Unpack the solver tarball in the
- Run the
configurescript to check all requirements and to create the settings file
rehashafterwards or in bash
source winenv.set.shto set all environment variables and build dmake.exe.
- Create the build tools using
- Build each module against the prebuilt
buildtool, followed by
Before you start building, you must ensure that your system satisfies the recommended software and hardware requirements for the type of system you are working on. For Windows, these are as follows:
- Windows NT Version 4 Service Pack 3 or higher, Windows 2000 SP 2 or higher or Windows XP.
A Microsoft Visual C++ Compiler. MS Visual C++ .net 2002 is recommended,
but MS Visual C++ Version 6 Service Pack 5 or 6 can also be used. Please note that
it is deprecated and no longer usable for the forthcoming 2.0 (680er codeline)
version of Openoffice.org and see also
a known problem with this compiler.
Below you find a list with additional requirements that have to be fulfilled for the different compilers.
Extra requirements for MS Visual C++ .net 2002:
- Install the ConvertDSW (wdevenv) utility. Get it from http://tools.openoffice.org/source/browse/tools/contrib/addin/bin/ and follow the instructions of the Readme.sxw in that directory.
- A Microsoft Assembly compiler.
It is included in .NET 2002, it can be found in the same directory as the
cl.exe). Look for
ML.EXE. If you use the
--with-cl-home=configure option you also have to use the
--with-asm-home=option pointing to the directory with the
Copy msvcp70.dll and msvcr70.dll to
$SRC_ROOT\external\msvcp70\. These dlls are part of the .NET installation and can be found in a directory similar to:
c:\Program Files\Microsoft Visual Studio .NET\Visual C++ .NET Professional - English\.
Extra requirements for MS Visual C++ 6 SP5 or SP6:
A Microsoft Assembly compiler. It can be found in the
Windows 98 Driver Developer Kit.
Additional instructions can be found at:
ML.ERRsomewhere in a directory in the system path or use the configure option
--with-asm-home=pointing to this location.
Warning! Do not use the Processor Pack for Visual Studio 6.0, it is proven to break the build.
midlc.exefrom the platform SDK. It has been reported in iz21023 that the versions that come with MS Visual C++ 6 do not work properly.
Parts of the February 2003 version of the Microsoft Platform SDK. The MDAC SDK,
the Core SDK and the Internet Development SDK have to be installed on your build system.
You can download them from
Important Note 1: Please ensure that you also select Build environment (Intel 64-bit) where available, when downloading the Platform SDK.
A Java 2 SDK. JDK 1.4
or newer is required.
Important Note 5: JDK 1.4.1 is proven to work, but JDK 1.4.2 is not supported for versions prior to OpenOffice.org 1.1.1, see issue 16626.
Cygwin Toolkit from
http://www.cygwin.com. Use at least Cygwin DLL version 1.5.10.
The official informations on using the setup.exe and installing Cygwin are available at:
More help and information on the Cygwin tools can be found at
When installing Cygwin make sure you set the "Default Text File Type" to "Unix". This is the default setting.
Not all Cygwin packages are needed to build OpenOffice.org, but make sure that at least all the packages from the base category and the following packages are installed.bison
The gpc general polygon clipper library release 2.31, located at
Download and unpack the tarball. You should have
the files gpc.c and gpc.h in
The Microsoft Layer for Unicode (unicows.dll). Get it from the Microsoft
site and put it into
$SRC_ROOT/external/unicows. (Note: Microsoft seems to enjoy changing the exact location of this file. You may have to search Microsoft's website.) Last time it was seen here.
The dbghelp.dll from Microsoft. Get it from the Microsoft
site and put it into
$SRC_ROOT/external/dbghelp. (Note: You may have to search Microsoft's website.) Last time it was seen here.
- Ant Is required to build some features. This is a Java make utility.
Important Note 6: Within the Cygwin Toolkit, three executables might be realised as symlinks, namely awk.exe, gunzip.exe and tar.exe. This might lead to a break of the build later, and the symlinks should be replaced with copies of the command they link to. Check, in a cygwin shell, with ls -l /bin/awk.exe whether awk.exe is a symlink. For instance, awk.exe could be a link to gawk.exe, in which case you should copy gawk.exe to awk.exe: cd /bin; cp gawk.exe awk.exe. Take similar action for unzip.exe and tar.exe.
Important Note 7:
If your cygwin installation includes the XFree86 packages make sure to
/etc/profile.d/00XFree86-bin.csh file. See
Important Note 8: Don't use Cygwin 1.5.7, there were some problems with this version. Upgrade to a newer release.
Perl - Optional requirements
For committers who want to use the CWS tooling. Install them like this.
|Crypt::SSLeay||for SSL encrypted SOAP connections|
|SOAP::Lite||access the SOAP based CWS webservice|
- Intel Pentium II PC
- 128 MB RAM (More recommended)
- 4 GB free disk space (8 GB for crashdump)
The code contains some further external components which are already provided. If you are interested in details about these, look at the External Components webpage at http://tools.openoffice.org/ext_comp.html.
You have two options to get the source code:
Download the source code tarball
oo_643B_src.tar.gzin case of the 643B release.
Unpack the tarballs as follows (for the 643B example):
> tar -xvzf oo_643B_src.tar.gz > cd oo_643B_src
This will be $SRC_ROOT from now on.
Another possibility is to check out the code from the cvs tree.
If you don't have a username and password, you can still do a checkout as
> cvs -d:pserver:email@example.com:/cvs loginThe non-bold slash means that the command should be in one line. It is possible to update an already existing older copy to a newer release:
Just press enter when prompted for the password.> cd $SRC_ROOT $SRC_ROOT> cvs / -d:pserver:firstname.lastname@example.org:/cvs / co -r OpenOffice_1_1_4 OpenOffice
$SRC_ROOT> cvs / -d:pserver:email@example.com:/cvs / update -r OpenOffice_1_1_4 OpenOffice
If you're only interested in building individual modules, you won't need
the entire source code. You can check out individual modules from the cvs
$SRC_ROOT> cvs / -d:pserver:firstname.lastname@example.org:/cvs / co -r OpenOffice_1_1_4 (module-name)
A note on the tags (i.e. the argument to the -r option in the cvs commands listed above): If HEAD is used as a tag, you will get the newest latest source code. This, however, will most likely not build since development is going on there. See http://tools.openoffice.org#CWS for a description of the development process with child workspaces and Environment Information System for the current child workspaces and milestones.
You use the
configure script to generate the build environment.
configure script checks that all software, hardware, and
system requirements for the build are satisfied, and it creates a
configuration file called
that you then run the
source command on to set all necessary
build environment variables. Don't forget to run rehash afterwards.
This configuration file will be moved into the
A top-level makefile script
makefile.mk and the
bootstrap in the
will be moved into
SRC_ROOT as well. This is due to technical reasons:
SRC_ROOT directory in the cvs tree can only hold directories.
On the other hand, the top-level
makefile.mk should logically be
placed in the top-level directory
SRC_ROOT. The cvs tree holds
these files in
Before running configure, make sure that all needed Programs are in the system path or start configure with the appropriate command line switches.
The following should demonstrate in detail what steps have to be done to set up the environment. For this examples we assume that
the source code is in
JDK 1.4.1_02 is installed in
the Microsoft Compiler is located in
C:\program files\microsoft visual studio\vc98)
the Microsoft SDK is located in
and the assembly compiler resides in
tcsh - ExampleYou have to enable the use of tcsh with
To run the
configure script, type the following command:
$SRC_ROOT> cd config_office config_office> ./configure --with-cl-home="/cygdrive/c/Programme/Microsoft Visual Studio .NET 2003/Vc7" --with-asm-home=/cygdrive/c/ml --with-jdk-home=/cygdrive/c/j2sdk1.4.1_02 --with-use-shell=tcsh
There are a number of options that you can use with the
script. To display these options, type the following command:
config_office> ./configure --help
configure, you have to source the configuration
file which sets all environment variables:
$SRC_ROOT> tcsh $SRC_ROOT> source winenv.set
Don't forget to run
afterwards. See the last screen from configure for exact details for your platform.
If you experiment with newest sources from the cvs-tree, mind that updates
to the configure process may not happen via updates of
(the script file) but via the files
set_soenv.in. The configure script itself is created from
configure.in using the
autoreconf command. The perl script set_soenv is created when you
run configure from set_soenv.in.
If you need to modify or create a correct configure you would run commands like the following:
$SRC_ROOT> cd config_office config_office> cvs update configure.in config_office> autoreconfTo update the
configurescript. If you only use code from the snapshot releases on the web, you don't need to be concerned about this.
To create the build tools, type the following command:
bootstrap utility creates the tools required for building.
This involves already building some modules and will take a few minutes.
If you decide to rebuild a module or build each module individually (mind
dependencies!), you will have to use the
build tool. A subsequent
deliver will copy all created binaries, libraries etc. into the
$SRC_ROOT/(module)> build $SRC_ROOT/(module)> deliver
The following table shows the time required to build on a system with a particular specification. You can use these details to estimate the time required to build on your system.
|Processor speed||600 MHz|
|Hard Disk||6 GB SCSI|
OpenOffice.org is organised in several projects. For example, the Word Processing Project. These in turn consist of several modules, organised in separate directories. The source contains approximately 90 modules.
You can build any project or module individually. Building modules
individually should not be misunderstood as reducing OpenOffice.org to a
special application, say, for instance, the spreadsheet application. The
program will always consist of the entire office suite: text processor,
spreadsheet, drawing application, etc. Building individual
modules comes in handy if you want to develop on a certain module.
Most modules will depend on other modules to be already built.
In other words, all modules must build in a particular order. To avoid
building all modules which are prerequisites of the module of your
interest, you can make use of a prebuilt
solver tree against
which you can build any module.
For more information on modules and on the sequence that they build in, and on the dependencies, see tools.openoffice.org/modules.html.
You have to download the
solver tree as a tarball. For example
from the Download page at
use a current release 643 is very old and only used as an example,
and unpack it in the
$SRC_ROOT directory, e.g.:
$SRC_ROOT> tar -xvzf solver643B_win32int.tar.gzIn order to create the build environment and build tools (bootstrap), you also have to check out the modules
config_office, dmake, external, xml2cmp, mkdepend, sal, solenv, vos, tools and rscpp.
To build a project, you build each of its modules individually in their
directory with the
build tool, followed by
to copy the created libraries, binaries etc. into the solver tree:
$SRC_ROOT/(module-name)> build $SRC_ROOT/(module-name)> deliverFiles called
build.lstin the directories
(module-name)/prjcontain all information about the subdirectories to be build (each of them containing makefiles
makefile.mk), about internal dependencies, and also about modules the current module depends on. The files
(module-name)/prj/d.lstcontrol the actions done by
deliver. The last or second to last directory to be build is usually module-name
/utilwhich is responsible for linking one or more shared libraries.
To rebuild a complete project with debug information, remove all object
files by removing the
directory. Then run
build with the debug option set to true:
$SRC_ROOT/(module)> rm -rf $SRC_ROOT/(module)> build debug=true
The build process (started with a top-level
build --all in
$SRC_ROOT/instsetoo) will create
installation sets in English and German.
$SRC_ROOT/instsetoo will also create the installation sets,
provided all other modules are already built.
If you have built an installation set earlier and want to re-build it, please delete the local outpath first:
$SRC_ROOT/instsetoo> rm -rf wntmsci9.pro
The English installation set will be located at
setup binary to install:
$SRC_ROOT> cd instsetoo/wntmsci9.pro/01/normal normal> setup.exeThe 01 in the path names indicates that the localisation is American English. This number corresponds to the international phone code for the USA. The German installation set will be located in a subdirectory 49. This scheme holds true for all localisations you may have chosen explicitly (see next section Building Localised Versions of OpenOffice.org).
For a network installation, use the
-net option to
setup. Details on the network installation process
can be found at
in the installation project webpage.
For information on creating an automated installation script and create a response file.
Running the configure script with the --with-lang option will introduce the build
of additional language resources. This option will introduce a command in the
environment settings file which in turn after execution sets a variable like, for instance,
TRUE in the case of french (You can also set
this variable by hand in order to introduce another language). It is also possible to
build more than one language at once.
One language resource, however, will not be
introduced that way: the help content! Clicking on 'help' would still open English
There is no automatic procedure yet to implement non-English help, but the additional manual effort is rather minimal: After building the source as described above, but before building the installation set, a zip-file with all help-content for the language of choice has to be unzipped into the directory
The filenames of these files contain a number code for the language, corresponding to
the international phone code of a country in which that language is mainly spoken.
For instance, the file
contains all help content for the Spanish localisation.
The zipfiles themselves are available at
Having unzipped the helpcontent files in there, building of installation sets can be resumed or repeated (in case you already have build some), as described in the previous chapter. English installation sets will be located in
where 01 corresponds to the international phone code of the USA. If you have chosen, for instance, French (by configuring with the
--with-lang=FRENoption) you will find an additional directory called 33:
Similarly, you will find 49 for German, 34 for Spanish, etc.
Localised help content is not yet available for all languages. In such cases, the English helpcontent will appear in the installations. For instance, when Danish is set with configure, you will find installation sets under the directory 45, but the help files will appear in English.