Apache OpenOffice Building Guide

From Apache OpenOffice Wiki
Jump to: navigation, search


This guide will help you to build Apache OpenOffice from its source code. It details the prerequisites and explains how to download the source code, prepare and then run the build. Step-by-step instructions for resolving the pre-requisites of individual platforms and building on them are available.

Here is the short version for the brave and impatient:

  • Download the source: svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo
  • Configure: cd main/ ; autoconf ; ./configure <some-switches> ; ./bootstrap
  • Build: source <platform-dependend-name>.sh ; cd instsetoo_native ; build --all
  • Wait for an hour or more (here you have to be patient)
  • Install office
  • Enjoy

The detailed description below gives a broader introduction into the build process and explains for the various steps.


This document is loosely based on an older version. I have tried to avoid duplication and to move anything that all platforms have in common to this page. Many details have been removed on purpose because they refer to older version of OpenOffice. However, there are still some things not explained in the necessary detail on this page:

  • How to use mozilla and nss.
  • How to use ccache


Getting help

You can get help by searching this wiki or by asking questions on the developers mailing list.

You can help us improve this guide by pointing out any errors (preferably after finding a solution). Or don't be shy and edit (and improve) these pages yourself.


In order to build Apache OpenOffice you need a proper environment. This includes

  • a command line interpreter, typically bourne shell compatible (sh or bash) inside a terminal. On Windows you will need to install Cygwin to provide it.
  • C++ compiler and linker. The exact choice depends on the operating system.
  • Perl interpreter and several modules.
  • Many tools from the Unix world like make or sed.

See section General Build Requirements for an exact list of requirements.

Getting the source

The source code is available as SVN repository at https://svn.apache.org/repos/asf/openoffice

Check it out with

  svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo

More details about how to check out source code from SVN can be found here.

The checked out files take up somewhat over 5GB on disk (more than 150000 files in more than 7000 folders and the SVN overhead).

After building this becomes (on Windows7) almost 17GB (more than 406000 files in more than 23000 folders).

You can use git as well. There exists no guide for this, therefore ask on dev@openoffice.apache.org, if you want to use git.

Organization of the source and output tree

The source code has five top level directories:

contains most of the so called modules. Each module typically provides one or more libraries. The source code of the writer application for example can be found in main/sd/.
contains the new automated testing framework
is the new home of modules that build external libraries (libraries maintained outside of Apache OpenOffice and often outside Apache).
contains the tar balls (archives) of external libraries. They are included both for convenience and to make sure that specific versions remain available. Note that the source package of the Apache OpenOffice release does not contain any external tar balls.
holds the localization data.

Most tools and scripts that are used for building are located below main/solenv/:

  • dmake makefiles in main/solenv/inc/
  • gmake makefiles in main/solenv/gbuild/
  • executables and perl files in main/solenv/bin/
  • perl modules in main/bin/modules/

Libraries and other output files that are shared between modules are stored in main/solver/.



Building Apache OpenOffice consists of three steps:

Detect platform, operating system, compiler, etc. and write the information into a shell script for later use. The developer can turn on or off certain features in this phase.
Compile the source code, transform other input files, apply localization.
Create a set of files, the installation set, that can be installed on the respective operating system. This can be msi/cab files for windows, deb or rpm for Linux, dmg for Mac.

The configure step has to be carried out only once. Building and packing is necessary after every source code change. There are short cuts to avoid parts of these steps (when you know what you are doing.)

General Build Requirements

The general requirements for all platforms are

Requirement Description Configure switch
Java JDK Java Implementation compatible with JDK 1.5 or JDK 1.6. OpenJDK is supported as well. --with-jdk-home=
Perl Perl 5. Also required are the perl packages

They can be installed from the shell with (you may have to run it with super user/administrator rights)

   perl -MCPAN -e shell

If it is executed for the first time then CPAN will ask for configuration. Choose autoconfiguration. Eventually the CPAN shell appeares accepts commands. Install missing modules with

   install <module-name>

Find more details here.6

CUPS cups headers. Provided by a cups-devel package or a libcups2-devel
PAM PAM support. Provided by a pam-devel package or a libpam-dev
Apache Ant Ant 1.7 or later --with-ant-home=
Archiver zip and unzip
gperf gperf tool
Mozilla1 Some Mozilla libraries are needed. Choose one of the following:
  • Get the source from here.2
  • Get prebuild libraries from here.3
NSS4 Mozilla build tools5 are needed for Windows. They can be obtained here.


  1. If you are a new developer, don't use the libraries. By using the --disable-mozilla switch for ./configure you waive the extra functionality.
  2. Copy the package into main/moz/download. The ./configure script will detect the source being present.
  3. You have to configure with --disable-build-mozilla to enable the use of the prebuild libraries. Place LINUXGCCI{inc,lib,runtime}.zip into main/moz/zipped. The files can be reused if the packages were build following the instructions of the previous point. In the latter case they can be found in main/moz/unxlngi6.pro of a successful build.
  4. UPDATE NEEDED, PLEASE HELP! The nss module will be introduced in DEV300m57. nss contains a subset of libraries from Mozilla (the moz module). They are supposed to be more current than those in the moz module. To prevent building nss and instead use the libraries from the moz module one can use the configure switch --disable-nss-module. This switch will be removed soon!
  5. Use the configure switch --with-mozilla-build to tell configure where the tools are installed. For example: --with-mozilla-build=c:/mozilla-build
  6. Please note that CPAN is not able to deal with usernames containing spaces. To work around this fact, when CPAN asks you to specify the CPAN build and cache directory, change the default suggestion to /cpan.

See also the platform specific requirements for

Configuration and bootstrapping

This is typically done only once after the source code is checked out. Repeat this after changing your mind about options given to configure.

The call to


creates the main/configure script from main/configure.in and some other input files.

The set of options/switches given to configure depends on the platform and your choice of features. A typical call starts like this

   configure                                                                                   \
       --with-dmake-url=http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2 \
       --with-epm-url=http://www.msweet.org/files/project2/epm-3.7-source.tar.gz                \

It tells configure where to find the source code of external tools dmake and epm.

By default only source code under category A licenses is compiled and included. Besides the Apache License 2.0 this includes for example BSD and MIT/X11 license. If you want to enable features that rely on third party code under category B licenses (like MPL, CPL, EPL, etc) then add the option


For inclusion of externaly hosted dictionary extensions add option


Note that dictionaries rely on a category B third party library (hunspell). Therefore --enable-category-b is a prerequisite for --enable-bundled-dictionaries. Dictionaries have a variety of licenses and are bundled without modification: they are not compiled.

You can run the rat scan while building with option


Here you can find details.

Finish this step by running


This will build dmake and epm, download missing source code tar balls of external libraries, and download missing external dictionary extensions.


Start by including the environment variables prepared by configure into your current environment with

  source <shell-script-name>

where <shell-script-name> depends on your platform:

platform id <shell-script-name>
wntmsci12 winenv.set.sh
unxlngi6 LinuxX86Env.Set.sh
unxlngx6 LinuxX86-64Env.Set.sh
unxmacxi MacOSXX86Env.Set.sh

Look into main/set_soenv for more platforms. (search for lines $OUTPATH = "<platform>"; and the nearby line $outfile = "<shell-script-name>";. Add the suffix .sh for the bash variant.

If you want to build the whole office and the install sets then

   cd main/instsetoo_native
   build --all

You may want to experiment with the -P options for multi process builds to reduce the build time.

   build --all -P<m> -- -P<n>

tells build to use m processes (build up to m modules in parallel) and n threads for each module.

Partial Builds

Building the whole office takes a lot of time. Therefore it may be preferable to build only parts after making changes to the source code. There are two different types of partial builds:

Can be used only when the code changes do not change exported interfaces. Use with care and only when you know what you are doing.
Use for code changes that modify exported C++ or IDL interfaces, that modify resources that are used by other modules, or when you are not sure.

For the following sections you should be aware that Apache OpenOffice uses two different make systems to build its modules.

  • The older one is based on dmake
  • The other and newer one is based on GNU make. This system is often referred to as gbuild.

When a module contains, among others, a Makefile and a Module_<module>.mk file then it is a gbuild module.

Compatible Build

After changing code in module <module> which does not change any exported interfaces do

dmake gbuild
   cd <module>
   cd <module>
   make -sr

No explicit call to deliver is necessary for gbuild modules.

to compile and deliver the resulting libraries to main/solver/. You may want to erase the output of a previous compilation:

dmake gbuild
   cd <module>
   build --from <module> --prepare

or faster (but without the un-deliver)

   cd <module>
   rm -fr <platform>/
   cd <module>
   make clean

Incompatible Build

Modifications that change exported interfaces require not only the module to be rebuild that contains the modified code. All depending modules (dependencies are defined in <module>/prj/build.lst) have to be rebuild as well. This is best done from main/instsetoo_native/:

 cd main/instsetoo_native/
 build --from <incompatible-module> --prepare
 build --from <incompatible-module>

The second line removes the output of all modules that have to be recompiled. The drawback of this command is that the output of modules which are build via gbuild are not removed. Thus, the following additional command performed after the second one will do the trick:

 build --from <incompatible-module> --job="make clean; make clean debug=t" --ignore

Frequently used options

In order to add debug information to libraries and executables, add the debug switch to any build or make command:

dmake gbuild
   cd <module>
   build debug=t
   cd <module>
   make -sr debug=t

Remember that for the gbuild system you have to used the debug flag also when cleaning a module (otherwise eg the wrong precompiled headers are deleted and are not rebuilt):

   make clean debug=t

You can force make to rebuild dependency information by first deleting it with the depend option. It is rebuild automatically with the next build:

dmake gbuild
   cd <module>
   build depend=t
   cd <module>
   make -sr depend=t
   make -sr
Personal tools