Contents

This page is intended as a collection of simple step-by-step recipes to build Apache OpenOffice from source code. A more thorough explanation of what the individual steps do and why they are necessary can be found in the building guide.

Ubuntu 14.04

The basic building steps under Ubuntu 12.04 (see below) are to be followed in Ubuntu 14.04 as well; however, there are some minor build issues that any developer, using this OS, needs to be aware of, if he gets stuck while building. The following is the list of issues, with their fixes, that a developer may face with:

As the BZ says, it is because of buggy toolchain g++4.9. So for now in Ubuntu Linux 14.04, build the source using g++4.8.2, gcc4.8.2; these are the default compilers in Ubuntu Linux 14.04 anyway; please check it using the following commands:

CentOS 5

CentOS 5 is our reference environment for build through the 4.1.x series. As it is a very old environment, it is not recommended to use it for your first build. But is important to document how to build on CentOS 5 since this is where the release through 4.1.x are built.

perl-Digest-SHA → This one is available on EPEL (sudo yum install epel-release && sudo yum install perl-Digest-SHA) but it is not worth to do that for a single module, as other modules must be fixed anyway

Once one works around bootstrap (for example, using a local package cache) build succeeds.

Windows 7, Windows 8.1

Complete requirements found at General Build Requirements and Building on Windows.
This is a sample step-by-step guide - check the complete requirements and report on dev@openoffice.apache.org, if problems with this step-by-step guide occurs.

Download files vcredist_x86.exe and vcrestist_x64.exe If you download the most actual version of Apache OpenOffice and unpack it, you will find the files vcredist_x86.exe and vcredist_x64.exe in folder redist. You can use them as well.

Get AOO source code. You can use the source release or check out from SVN. Build from source release if you want to build OpenOffice once but don't want to contribute patches. If you will contribute patches, you need to generate them against an actual version of trunk. In this case check out from SVN to be able to rebase before generating patches. You can work with subversion or with git-svn. Do not use a tool that changes line endings, such as the default configuration of TortoiseSVN.