Development/Native Build From Bootstrap

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:

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'):

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?):

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     to   , and the configure process will   pre-set number of jobs to use, and will try to find the icecream gcc   wrappers in. Should you have  them somewhere else, please use       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

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

and for MacOS

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

Fetch
The first time only, run

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.

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 )

Start what you have build
To run the LibreOffice you have just build, do 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 :

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

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.

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

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

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' where  is the  parallelism degree you want.

If you're adding new features to an existing lib, you'll have to issue    to make your changes visible to other  modules. It will basically copy content of   to    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 instead of the old   alias. Please note that   is not necessary with the new build  system outputs objects directly to.

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    as a build's parameter, like:

The syntax is similar for the new build system:

Verbose build
If you want to get verbose output during build:

with gmake:

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

with gmake:

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:

with gmake:

See other useful commands you can use (GNU make only)
To see other available options during partial module build, run:

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:

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

Then you want to go to the directory named after the module that failed, here '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:

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.

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_, ,.... (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="  ... " 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:

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

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