Preface

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.

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.

Getting the source

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

Space Requirements

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:

main/

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/sw/. More information on the organization of the modules in the source code directories here.

is the new home of modules that build external libraries (libraries maintained outside of Apache OpenOffice and often outside Apache).

ext_sources/

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.

extras/

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

Overview

Building Apache OpenOffice consists of three steps:

Configuring/bootstrapping

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.

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.)

The building examples in this wiki document use only command line approaches to building. Depending on your expertise, it may be possible to use an IDE which allows specification of custom build scripts.

General Build Requirements

The general requirements for all platforms are

Requirement

Description

Configure switch

Java JDK

Java Implementation compatible with JDK 1.7 or higher. OpenJDK is supported as well.

For Windows JDK 1.7 or JDK 1.8 is recommended.
The JDK's bitness must match the target platform's, eg. when building for Win32, use a 32 bit JDK even if compiling on Win64.

--with-jdk-home=

Perl

Perl 5 - note: for Windows Perl will be installed as part of the cygwin environment.

Also required are the perl packages

Archive::Zip

XML::Parser

LWP::UserAgent

Digest::SHA

Digest::MD5

LWP::Protocol::https

On Linux, use whenever possible your package manager to install the required modules. On Windows, use cygwin's setup-x86.exe.

The name of packages varies depending on the system:

Perl Module

CentOS/Fedora

Debian/Ubuntu

Windows/cygwin

Archive::Zip

perl-Archive-Zip

libarchive-zip-perl

perl-Archive-Zip

XML::Parser

perl-XML-Parser

libxml-parser-perl

perl-XML-Parser

LWP::UserAgent

perl-libwww-perl

libwww-perl

perl-libwww-perl

Digest::SHA

perl-Digest-SHA

perl

perl-Digest-SHA

Digest::MD5

perl-Digest-MD5

perl

perl

LWP::Protocol::https

perl-LWP-Protocol-https

liblwp-protocol-https-perl

perl-LWP-Protocol-https

On some rather old systems, LWP::Protocol::https is installed in the same package as LWP::UserAgent; in this case, you need to install further dependencies in order to use LWP::UserAgent with the HTTPS protocol with no errors; on CentOS 5, for example, you need to install the Crypt::SSLeay module, provided by the perl-Crypt-SSLeay package.

On Mac OS X, bootstrap may fail to download external dependencies from HTTPS URLs (you may get an error with a message like "Can't verify SSL peers without knowing which Certificate Authorities to trust"), even if configure found all required modules; in this case, install the Mozilla::CA module using cpan.

On CentOS, perl-Digest-SHA might be only provided through the EPEL repository.

The prefered way to install Perl modules is using your system's package manager; alternatively, and as last resort, Perl modules 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 appears accepts commands. Install missing modules with

Required for building the ODK which is included in the build unless disabled. This file is required for non-Windows builds. Without this file, configure will try to set up cross-compiling with windows.
NOTE: Not for windows. Required on all non-windows platforms. Download by directly saving unowinreg.dll into /main/external from the link provided above, or by using wget:

NSS is provided by the Mozilla project. Building it on Windows requires the MozillaBuild tools. Get the latest version, install it and use the configure switch --with-mozilla-build to tell configure where the tools are installed. For example: --with-mozilla-build=c:/mozilla-build

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.

Apache Ant: Assure a proper ant set-up by downloading and installing ant, in total, from the ant site linked above. If you are a Linux developer, your distro may not have ant setup correctly for building Apache OpenOffice.

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

--enable-category-b

For inclusion of externally hosted dictionary extensions add option

--enable-bundled-dictionaries

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.

The --with-lang option will introduce the build of additional language resources. This switch accepts one or more RFC 1766 language tags as arguments, unfortunately not all languages are supported. Check the solenv/inc/langlist.mk file for all the currently supported language tags. The environment variable WITH_LANG will then contain the language tags of the additional (en-US will always be build) languages. Example:

--with-lang="de fr"

enables the build of the localized German and French version.

To build with symbolic generation, add option

--enable-symbols

This would allow you to work with debugging symbols in gdb.

Another useful option for interactive debugging features is dbgutil. Add option,

--enable-dbgutil

for this feature. Also see the Debugging information on this page.

By default the result binaries will be packaged in the default format used by your OS/Distribution. Using 'installed' for package format puts OpenOffice into your installset directory (browse down ../installed/install). This will save you time for testing since you can then directly run OpenOffice from this area.

Add option

--with-package-format="installed"

This will speed up development process since it skipped packaging. In some cases, packaging rips the debugging symbol so this would be necessary for symbolic generation. NOTE: Additional package format options will be ignored with the "installed" option.

Building Apache OpenOffice uses a custom build command, build.pl, located in /main/solenv/bin.
You may find it helpful to learn more about build options from the Build Documentation

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:

Compatible

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.

Incompatible

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.

If you are a new developer, you should probably always assume your changes are "incompatible" and follow the instructions for Incompatible Build.

Make Systems Used by Apache OpenOffice

For the following Build 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>
build
deliver

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. In some cases a new compilation will not work correctly unless the old output is removed.

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/:

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: