TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

This page was marked as inactive and is retained for historical reference.
Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as one of our mailing lists.

This page documents how to build older versions of LibreOffice, such as releases 3.3 and 3.4; how to build the current development version is documented here.

There are two main methods of building LibreOffice. One is based on a git repository named 'build', the other on a git repository named 'bootstrap'.

The method based on the 'build' repository is deprecated.

The method based on the 'bootstrap' repository is the method described here (it is more efficient, faster and much more developer friendly with regards to code change and partial build).

Preparation

Dependencies

The first step is to make sure that you have all the dependencies needed for your platform to build the product. There are pages that details what they are and how to install them for Windows, Linux, and MacOS.

Disk Space

At minimum, with all the git repositories, and the product build and packaged, you will need anywhere from 7 to 10 GB of disk space, depending on the platform, the build options and the specific autogen options you use, few Gb more if you make a debug build.

Bear in mind that if you want to do more than just building the product once for your own enjoyment, you most likely will want to have more than one working directory (we will see later how to set them up). A workdir allow you to have a separate build environment without having to duplicate the git history, but it will still cost you 6 to 9 Gb per workdir.

Getting the sources

In the rest of this tutorial we will work in ~/git, of course you are free to choose which ever directory you want as a starting point. Now let's download the 'bootstrap' git repository:

$ mkdir git
$ cd git
$ git clone git://anongit.freedesktop.org/libreoffice/bootstrap libo
Cloning into libo...
Remote: Counting objects: 76845, done.
remote: Compressing objects: 100% (17328/17328), done.
remote: Total 76845 (delta 60786), reused 74045 (delta 58579)
Receiving objects: 100% (76845/76845), 15.82 MiB | 1.17 MiB/s, done.
Resolving deltas: 100% (60786/60786), done.
$ cd libo

Checking out the release branch

By default git will give you the 'master' branch for a new clone, which is not what you want. To change your working copy to a release branch, first do this (before running 'autogen.sh'):

$ git checkout -b libreoffice-3-4 origin/libreoffice-3-4

After you have cloned the other repositories (see 'make fetch' below), do this to switch them to the release branch as well, and update the symlinks (is it really necessary to do this manually?):

$ ./g checkout -b libreoffice-3-4 origin/libreoffice-3-4
$ for d in ${PWD}/clone/*/*; do ln -sf ${d} .; done

Performance

Building LibreOffice takes time, a lot of time. Exactly how much depends on how powerful your machine is. But there are tools you can use to speed-up things.

ccache

ccache is a tools that cache the result of c/c++ compilation to try to re-use them later. It will not speed-up your initial build (on the contrary it will slow it down a bit), but it can dramatically speed up later re-build. If you plan to do some hacking in LibreOffice, you will do that a lot, so it is a worthy tool to have.

distcc / Icecream

If you are in an environment where you have access to multiple machines with spare cpu cycles, you can take a look at distcc or icecream, tools for distributed build.

Support for Icecream is built into LibreOffice, it is enough to add --enable-icecream to ./autogen.sh, and the configure process will pre-set number of jobs to use, and will try to find the icecream gcc wrappers in /opt/icecream/bin. Should you have them somewhere else, please use --with-gcc-home=/path/to/your/icecream/bin switch to override that.

--with-max-jobs / --with-num-cpus

The build process can be told to run multiple task in parallel. The overall parallelism is controlled by the autogen parameter --with-max-jobs and the parallelism within a sub-task is controlled by --with-num-cpus. If you have enough memory, I found that using --with-max-jobs=n --with-num-cpus=n where n is your number of cores, or 2 for --with-max-jobs if you have only 1 core, give me the fastest build time.

--with-max-jobs defaults to 1, and --with-num-cpus defaults to the the number of cores/cpus on your system. Note that their net effect is multiplicative, there can be up to their product of simultaneous work (compiler) processes.

Approximate times

An Athlon 435 X3 with ccache without java without epm takes about 1.5 hours for the initial make on gentoo.

Autogen

You need to configure your build, this is done by running a script named 'autogen.sh'. There are many options that can be given to that scripts, you can get a list of them by running

$ ./autogen.sh --help
'configure' configures LibreOffice 3.3 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
[....]

You mileage may vary, depending on your platform and distribution. To get us going here is the autogen I use for linux

$ ./autogen.sh --with-num-cpus=6 --with-max-jobs=6 --without-junit

and for MacOS

$ ./autogen.sh --with-max-jobs=8 --with-num-cpus=8

Please refer to this page for more detailed descriptions of build configuration options.

Parameters to autogen.sh to fix common problems

--disable-epm This will fix "rpm not found", as autogen expects to find either dpkg or rpm on the system.

--without-java This will fix "ant not found"

Note: Installing 'libgnomevfs2-dev' package on Ubuntu manually will fix "No package 'gnome-vfs-2.0' found". Use synaptic package manager or run in terminal

$ sudo apt-get install libgnomevfs2-dev

Fetch

The first time only, run

$ make fetch

This will download the other git repos and needed tar.gz packages. Note that make will do this step anyways if you don't do it manually, but doing a make fetch the first time allow you to monitor the download activity.

Building

First Build

The first time make is invoked, it will download all the other git repository needed and possibly other packages to be downloaded. This part will download north of 1Gb of data, so be patient... After the git repositories are cloned make will continue on building the product. That step can take 8/number_cores hours on a reasonably recent processor, and probably twice that on Windows.

$ make 2>&1 | tee build.log
===== artwork =====
Cloning into artwork...
Creating missing link default_images
Creating missing link external_images
Creating missing link ooo_custom_images
===== base =====
Cloning into base...
Creating missing link dbaccess
Creating missing link reportdesign
===== calc =====
Cloning into calc...
Creating missing link chart2
[...]

Note that in the command above, a simple 'make' would have been sufficient. The rest of the command is to save all the output of the make into a file (build.log), so that you can go back to it later to investigate if needed.

( With a fresh git clone, download and corresponding make might take some time. To avoid accidental killing of the process, one can do a nohup make as below )

$ nohup make & 
nohup: ignoring input and appending output to `nohup.out
$ tail -f nohup.out

Start what you have build

To run the LibreOffice you have just build, do

$ make dev-install

and the output will show how to start the program. Typically this is ../libo/install/program/soffice, which comes from the Makefile

Re-build

If you modify the sources, or pulled your git repositories with the lastest update, you can rebuild by simply running :

$ make

Sometimes, often because some header file got removed or renamed, it is necessary to do a full-blown rebuild.

$ make clean && make

Partial build

Of course, due to the time it takes, a full rebuild is not the first recourse. When something goes wrong in a specific module, you can rebuild just that module.

First you need to 'source' the build environment. You need to do that only once in a given shell session.

$ source *Env.Set.sh

then go to the directory of the offending module, for example

$ cd sw

From there you can build again the module, by using the command 'build', or rebuild the module entirely with

$ rm -r $INPATH ; deliver -delete
$ build

Note: the parallelism value you did set-up in autogen will not be automatically picked up when you run 'build' manually. To tell build to use more than one CPU, use 'build -- -P<n>' where <n> is the parallelism degree you want.

If you're adding new features to an existing lib, you'll have to issue deliver to make your changes visible to other modules. It will basically copy content of <module>/unxlngi6.pro to solver/330/unxlngi6.pro where everyone look for headers.

For modules using the new gmake build system, by using the command 'make -sr', or rebuild the module entirely with

$ make -sr clean
$ make -sr

instead of the old build alias. Please note that deliver is not necessary with the new build system outputs objects directly to solver/330/unxlngi6.pro.

Partial debug build

Should you need to do a debug build of a module, to see more of the debugging messages during the LibreOffice run, you can add debug=build as a build's parameter, like:

$ rm -r $INPATH
$ build debug=true

The syntax is similar for the new build system:

$ make -sr clean
$ make -sr debug=true

Verbose build

If you want to get verbose output during build:

$ build verbose=t

with gmake:

$ make -r

Getting debug output

If you want to get the output of OSL_TRACE() calls and other debug messages:

$ build debug=t dbglevel=2

with gmake:

$ make -sr dbglevel=2

Getting debug symbols

If you want to enable symbols for profiling, debugging with gdb etc, but don't want to turn on debug outputs or change compiler optimization settings, run:

$ build -- ENVCFLAGS+=-g

with gmake:

$ make -sr ENABLE_SYMBOLS=true

See other useful commands you can use (GNU make only)

To see other available options during partial module build, run:

$ make help

Note that this is different from running make -h, which lists commands for the GNU make itself.

The Build Failed... What can I do ?

Using a cutting edge development branch means that you are, more often than not, going to get cut. Things will not quite work as expected.

Here is an example of a failed build. My build messages ended with:

Making:    libslideshowtestlx.so
slideshow deliver
Module 'slideshow' delivered successfully. 2 files copied, 2 files unchanged

-----------------------------------------------------------------------
        Oh dear - something failed during the build - sorry !
  For more help with debugging build errors, please see the section in:
            [[Development]]

  internal build errors:

ERROR: error 65280 occurred while making /lo/libo/connectivity/source/cpool

 it seems that the error is inside 'connectivity', please re-run build
 inside this module to isolate the error and/or test your fix:
-----------------------------------------------------------------------
[...]
make: *** [all] Error 1

First things: do not post that on the mailing list. The only useful information in all this is that the module 'connectivity' could not be built for some yet unknown reason.

To get a more useful output, to track down what happened, or at least to provide enough information so that somebody else may be able to help you, you need to 'Source' the file *Env.Set.sh (if have not done that already in the shell session you are in).

$ source *Env.Set.sh

Then you want to go to the directory named after the module that failed, here 'connectivity'

$ cd connectivity

And from there you can re-start the build for this particular module using the 'build' command.

Here is the (partial) output for the build command:

$ build
build -- version: 275224

=============
Building module connectivity
=============
Entering /lo/libo/connectivity/inc
[...]
Entering /lo/libo/connectivity/source/cpool

Compiling: connectivity/source/cpool/ZConnectionPool.cxx
/lo/libo/clone/libs-core/connectivity/source/cpool/ZConnectionPool.cxx:  In constructor 'connectivity::OConnectionPool::OConnectionPool(const  com::sun::star::uno::Reference<com::sun::star::sdbc::XDriver>&,  const  com::sun::star::uno::Reference<com::sun::star::uno::XInterface>&,  const  com::sun::star::uno::Reference<com::sun::star::reflection::XProxyFactory>&)':
/lo/libo/clone/libs-core/connectivity/source/cpool/ZConnectionPool.cxx:98: error: 'TimeValue' is not a member of 'salhelper'
dmake:  Error code 1, while making '../../unxlngx6.pro/slo/ZConnectionPool.obj'

[... supressed nice messages explaining you succinctly what to do ...]

Now, that is better. I look at the indicated file and realize that I accidentally (on purpose for your entertainment) removed a T in front of TimeValue, which should read TTimeVaue... I quickly fix the problem and run the build command again to be sure. Then I can go back to run the make command again.

If you cannot figure out what is going on, you can try to force a rebuild of the module.

Build tips

Disable mozilla

If you are having build issues related to mozilla, consider disabling it altogether by using --disable-mozilla configure option. Mozilla code is used for features such as macro security settings and digital signatures. So, if you don't need these features in your development build, it's safe to disable mozilla.

Windows multi-language installer

In order to build a multi-language installer on Windows, first complete the build to the end, then do

 cd instsetoo_native/util
 dmake openoffice_<locale>,<locale>,....   (comma separated list of locales)

where you specify the locales you want to include in the installer. Don't forget to build with --with-lang="<locale> <locale> ... " in order to make those locales available during the build.

Multiple Work Dirs

If you want to work on both the master branch, and the current release branch at the same time, you can share git repos, and external source tarballs (note the savings can be significant, especially if you also use the quite huge l10n repo). Note that switching branches within the same working dir is not recommended - the build dependencies for LibreOffice are still somewhat incomplete and fragile, and you'd likely have to perform clean re-compilations everytime you switch branches. If you can afford the diskspace, maintaining separate trees is the recommended way.

Setup

Prepare the first build on your disk just like explained above. For the second, and all other builds, do this to clone the initial bootstrap repo:

$ /other/libo/bin/git-new-workdir /other/libo /dir/to/be/created my-libo-branch

You'll notice a much quicker clone operation. After that, setup the new work dir with these two extra configure (or autogen.sh) options:

$ ./autogen.sh ... --with-linked-git=/other/libo/clone --with-external-tar=/other/libo/src
$ ./g checkout my-libo-branch

Again, cloning will be much faster. After that, you proceed with building just like for the single-workdir case.