Supervisión del Código

    From The Document Foundation Wiki

    Como compilar LibreOffice

    Getting you first successful build of LibreOffice can be an intimidating and daunting task. Here is a walkthrough that should guide you towards getting your first build finished.

    Librerias requeridas/Dependencias


    The commands below should prepare a regular system into one able to build LibreOffice, it is by far the easiest way to use the existing package to bootstrap your build dependencies.

    sudo apt-get build-dep && sudo apt-get install git libgnomeui-dev gawk # Debian & derivatives
    sudo zypper si -d OpenOffice_org-bootstrap # for OpenSUSE
    sudo yum-builddep # for Fedora & derivatives

    If this fails, on some Ubuntu systems (10.10, maybe earlier versions) try this:

    sudo apt-get install git build-essential gawk libxml2-dev libfontconfig1-dev \
    libpam0g-dev libpng12-dev flex bison libgtk2.0-dev openjdk-6-jdk libcups2-dev \
    gperf libxaw7-dev libgnomeui-dev libgstreamer-plugins-base0.10-dev \
    libgl1-mesa-dev libglu1-mesa-dev
    sudo perl -MCPAN -e 'CPAN::Shell->install(Archive::Zip)'



    On Windows, you must first install cygwin from, once you've run the the setup.exe utility, switch the package view mode to 'Full', then select the following packages for installation:

    1. autoconf
    2. automake
    3. bison
    4. cabextract
    5. flex
    6. gcc-g++
    7. git
    8. gnupg
    9. gperf
    10. libxml2-devel
    11. libpng12-devel
    12. make
    13. mintty
    14. openssh
    15. openssl
    16. patch
    17. perl
    18. pkg-config
    19. readline
    20. rsync
    21. unzip
    22. wget
    23. zip

    Herramientas de Windows

    A Microsoft Compiler and debugger is also required, and should be downloaded from:, Visual Studio 2008 Express should work, and work is underway to ensure that VS 2010 is also supported.

    Nombre de directorios y rutas

    To have a successful build, we recommend that you use a short directory name in the root directory of one your hard disks, such as c:\lo, as long path names can cause the build to fail in weird and wonderful ways. Secondly, the build system requires you to use

    'cygdrive' paths, which encode the current drive as well as the path in the form of: /cygdrive/c/lo for example. To ensure that these paths

    are used, enter the directory containing the git repository by using, for example:

    ~$ cd /cygdrive/c/lo

    Supervisión de los recursos de Git

    First you need to have a copy of the source code. This is done by first downloading the 'root' repository,

    ~/git$ git clone git:// loroot

    and then using the first few step of the build process to pull all the other repositories.

    ~/git$ cd loroot
    ~/git/loroot$ ./ --with-git --with-num-cpus=2
    ~/git/loroot$ ./download

    The ./download step will take a while. This is because git is downloading the entire history of the project. But don't worry, only the first download will take a long time. After this git will only fetch new things that have been added since the last time you pulled.

    Now you should have a loroot that looks something similar to:

    ~/git/loroot (master)$ ls
    AUTHORS				aclocal.m4			intltool-update
    COPYING			download.list
    COPYING.LGPL			autom4te.cache	m4
    ChangeLog			bin	man
    INSTALL				build				emacs.el			missing
    MAINTAINERS			clone				etc				patches
    Makefile			config.log			extensions			po			config.status			git				rawbuild			configure			git-hooks			scratch
    Makefile.shared			install-sh			src
    NEWS				desktop				intltool-extract		stamp
    README				distro-configs		templates
    TODO				doc				intltool-merge			test
    TOTEST				download

    'clone' is the directory where all the other repositories are setup. 'rawbuild' is where you go to build a pure libre-office.

    Let's have a closer look at clone:

    ~/git/loroot$ ls clone
    artwork		calc		extras		impress		libs-extern-sys	repos_changed	ure
    base		components	filters		libs-core	libs-gui	sdk		writer
    bootstrap	extensions	help		libs-extern	postprocess	testing

    So here you are, 20 git repos, the 19 listed above plus the root repository.

    For a more detailed discussion of each of these directories, and what they contain - please see the Code Overview for more details.

    Primera compilación

    On a fresh download, the rawbuild directory is not created yet. Let's fix that:

    ~/git/loroot $ ./bin/g pull -r

    Now, go to the directory named 'rawbuild'

    ~/git/loroot $ cd rawbuild
    ~/git/loroot/rawbuild $

    This directory contains dozens of links, pointing back to the content of our 19 git repositories contained in 'clone', plus a few files needed to be able to build.

    You need to configure your build environment. There are plenty of options. You can see them all by running:

    ~/git/loroot/rawbuild $ ./ --help

    But if you are running a fairly standard recent Linux box, the following should be safe:

    ~/git/loroot/rawbuild $ ./ --with-num-cpus=5 --without-junit --disable-kde

    Replace the 5 above by your number of processors + 1.

    Now you can actually launch the build itself. The build produces a lot of messages... Most of the time you need not be concerned with them, but sometimes you need to figure out what happened, so I usually redirect the ouput to a file, to be able to mine through it later if need be:

    ~/git/loroot/rawbuild make 2>&1 | tee build.log

    At this point, you can find something else to do... A full build can easily take hours (with an s).

    If everything went well, the build is successful and now you can run:

    ~/git/loroot/rawbuild make dev-install

    And if that step was successful too, you should see something like:

    soffice files [soffice.bin] [bootstraprc] [intro.bmp] [share]
    Creating '~/git/loroot/rawbuild/install/LibreOffice/installed/install/en-US/program/ooenv'
    linkoo finished, please don't forget to source ooenv before ./soffice.
    Developer installation finished, you can find it here:

    Which tells you where to find your brand new libreoffice executable!

    La compilación fallo... Que puedo hacer?

    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:

    Module 'slideshow' delivered successfully. 0 files copied, 4 files unchanged
    drawinglayer deliver
    Module 'drawinglayer' delivered successfully. 0 files copied, 99 files unchanged
    odk deliver
    Module 'odk' delivered successfully. 1 files copied, 3 files unchanged
    1 module(s): 
    need(s) to be rebuilt 
    ERROR: error 65280 occurred while making ~/git/loroot/rawbuild/connectivity/source/cpool
    Attention: if you fix the errors in above module(s) you may continue the build issuing the following command:
    build --from connectivity
    make: *** [all] Error 1

    So, 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 to us reason.

    So how 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 ?

    The first thing you need to do is to 'source' the file * (I have 64-bits linux box, so that file is name in my case)

    ~/git/loroot/rawbuild $ source *

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

    ~/git/loroot/rawbuild $ cd connectivity
    ~/git/loroot/rawbuild/connectivity $

    It happens from time to time that some conflicting change needs to remove the previous build output. To do this, run:

    ~/git/loroot/rawbuild/connectivity $ rm -r $INPATH ; deliver -delete

    And from there you can re-start the build for this particular module using the 'build' command. 'build' is a shell alias to a perl-script, that parses prj/build.lst to work out what can be built, and how much parallelism the code can cope with.

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

    $ build
    build -- version: 275224
    Building module connectivity
    Entering ~/git/loroot/rawbuild/connectivity/inc
    Entering ~/git/loroot/rawbuild/connectivity/source/cpool
    Compiling: connectivity/source/cpool/ZConnectionPool.cxx
    ~/git/loroot/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>&)':
    ~/git/loroot/clone/libs-core/connectivity/source/cpool/ZConnectionPool.cxx:97: error: 'TimeValue' is not a member of 'salhelper'
    dmake:  Error code 1, while making '../../'

    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 the rawbuild directory to run the make command again.

    If you cannot figure out what is going on, you can try to force a rebuild of this module. The rationale for doing that is that sometimes the build system ('make') doesn't get all the dependencies right. To do that you must remove a directory called *.pro located in the module's directory, and then run the 'build' command again.

    Que mas debes saber del sistema de compilación?

    Internally, LibreOffice uses dmake, and you will have to set some (well, many actually) environment variables to the correct values. On Linux, do that with: 

    cd build/libreoffice*
    source Linux*

    On Windows, with: 

    cd build/libreoffice*
    source win*

    etc. (Note that the "." command can be used instead of "source" and is shorter to type.)

    After that you can build single modules with

    cd <directory-that-failed>

    'build' is a  shell alias to a perl-script, that parses prj/build.lst to work out what can be built, and how much parallelism the code can cope with.
    You can also run dmake manually after sourceing those environment variables as stated above. Afterwards just issueing


    should work. There are some useful flags to dmake and build - the most important are:

    verbose=1 # let me see the compile lines
    debug=true # enable assertions and debugging symbols
    -P10 # do 10 builds in parallel ;-)