Dependencias de compilación

Encontrará más información en la página Dependencias de compilación en Linux.

Por lo general, compilar LibreOffice en Linux es más sencillo que en otras plataformas.
Instale primero las dependencias de compilación:

• En Debian/Ubuntu: sudo apt-get build-dep libreoffice
• En OpenSUSE 11.4+: sudo zypper si -d libreoffice
• En Fedora 22+ y distribuciones derivadas: sudo dnf builddep libreoffice
• En RHEL 7+ y distribuciones derivadas: sudo yum-builddep libreoffice
• En DragonFly cd /usr/dports/editors/libreoffice && make patch
• En FreeBSD cd /usr/ports/editors/libreoffice && make patch
• En NetBSD cd /usr/pkgsrc/misc/libreoffice && make depends

Observe que las órdenes anteriores podrían no instalar todo lo necesario, ya que utilizan los paquetes de la distribución como fuente de dependencias. Esto refleja la versión de LibreOffice que la distribución ha empaquetado, así como los parámetros que se han empleado para compilar dichos paquetes.
Para obtener más información sobre otras distribuciones, tales como Arch, consulte la página sobre las dependencias de compilación en Linux.

Clonar y compilar

Acto seguido, clonaremos el repositorio y comenzaremos la compilación:
La orden make es la que demora bastante más tiempo que las otras la primera vez que se ejecuta. git clone también puede tardar algún tiempo.
Consulte las notas de más abajo para encontrar otras opciones que utilizar con autogen.sh (p. ej., compatibilidad de depuración adicional).

Ejecutar la compilación

Esto creará una instalación local, la cual puede iniciarse con las órdenes siguientes:

Detalles, consejos, trucos y pistas

Preparación

Dependencias

Esta página documenta cómo compilar la versión de desarrollo actual de LibreOffice, basada en un repositorio de Git denominado «core».
Vea también Dependencias de compilación en Linux.

Espacio en disco

Como mínimo, con los repositorios Git y el producto compilado y empaquetado, necesitará unos 26 GB de espacio en disco. Esta cifra variará en función de la plataforma, las opciones de compilación y las opciones de autogen.sh que utilice; añada unos cuantos gigabytes más si está realizando una compilación para depurar.
Si está trabajando en varias funcionalidades simultáneamente, puede utilizar git stash o configurar más de un directorio de trabajo (más adelante veremos cómo configurarlos). Un directorio de trabajo le permite tener un entorno de compilación separado sin tener que duplicar el historial de Git, pero aun así le costarán de 6 a 8 GB de espacio por directorio de trabajo.

Recuperar el código fuente

Por el resto de este tutorial trabajaremos en ~/git. Evidentemente, puede elegir cualquier carpeta que quiera como punto inicial.
Descargue el repositorio Git denominado core:

autogen.sh

Ahora debe configurar su compilación. Esto se lleva a cabo mediante la secuencia de órdenes autogen.sh.
Existen muchas opciones que pueden utilizarse en esta secuencia de órdenes. Después de ejecutar autogen.sh por vez primera, puede consultar una lista de las opciones al ejecutar:
El resultado puede cambiar en función de su plataforma o distribución. Estos son algunos ejemplos:
La opción --enable-dbgutil crea una compilación para programadores, en la cual se desactivan las optimizaciones y se activan la compatibilidad con depuradores y otras comprobaciones.

Consejos

Ejecución dentro de un depurador

Para iniciar la compilación directamente dentro de un depurador:
Then you can open Writer with the command:
Note that soffice.bin will be terminated the first time it is run directly (or via make debugrun), this is normal, you simply need to run it again to make use of it. Running soffice will deal with this for you.

Activar las alertas

Various versions of GCC are well-known to emit more/unhelpful/bogus warnings at higher optimization levels. Don't even try to combine
build with GCC.

Rendimiento

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 tool that caches the results 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-building. If you plan to change lots of header files in LibreOffice, it is a worthy tool to have.
By default, ccache will be enabled automatically if it is found on your system. For best results, you may want to increase the cache size or enable cache compression; `man ccache` is your friend.
Note that the default cache size is just 5GB which is far too small to be useful for a LibreOffice build; for a build without debug symbols, you should have at least 8GB cache, and for a build with debug symbols for everything probably 32GB is a useful starting point. You can set the size like this (note that this setting is stored inside the cache directory, if you change the location by setting $CCACHE_DIR you have to re-do it):

ccache --max-size 32G

ccache also supports compression, which is very likely a good idea to enable (does anybody have hard numbers?), especially if you are using a small or slow storage medium, like a SSD or laptop hard disk. You can enable compression by adding this to your .bashrc or equivalent:

export CCACHE_COMPRESS=1

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 icecream or distcc tools for distributed build. Icecream is recommended and easier to setup.
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 /usr/lib/icecc/bin or in /opt/icecream/bin. Should you have them somewhere else, please use --with-gcc-home=/path/to/your/icecream/bin switch to override that.
To make use of distcc, first install and start distccd on all the build machines and make sure all the compiler versions are compatible (this is important for C++ code). Now on the driving machine install and configure distcc to use the other build hosts. Then pass --with-parallelism=N to autogen.sh, where N is the total number of CPUs available in your cluster and run distcc-pump make CC=distcc CXX=distcc to start the distributed build.

--with-parallelism

The build process can be told to run multiple tasks in parallel. The parallelism is controlled by the autogen.sh parameter --with-parallelism. If you have enough memory, I found that using --with-parallelism=n where n is your number of cores, or 2 for --with-parallelism if you have only 1 core, give me the fastest build time.
--with-parallelism already defaults to the the number of cores/cpus on your system, unless you use --enable-icecream - then to 10.

--with-system-libs

Building with existing libraries may speed up your build, but you have to fiddle with the dependencies.

Tiempos aproximados

An Athlon 435 X3 with ccache without java without epm takes about 1.5 hours for the initial make on gentoo.
The first build, on an Intel 2630QM with ccache without java and epm with --with-parallelism at 8 and ext4 formatted disk takes about 1,5 h too on Kubuntu. The following daily build time varies between 2 and 10 min (depending on the number of modified or added files and their complexity).

make con salida detallada

Make will hide the exact command invokations. To see what make does exactly for a single run one can invoke it as

Directorios de trabajo múltiples

If you want to work on both the master branch, and the current release branch(es) 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 between different release branches within the same working dir is not recommended; even if there are no dependency problems, the amount of stuff you'd have to rebuild is practically equal to a clean rebuild. If you can afford the diskspace, maintaining separate trees is the recommended way.
There are two methods to share git repos across working directories: git clone --reference and git-new-workdir. A referenced clone can avoid re-downloading the repo, but the new workdir will still have its own .git/config, etc. This is supported by upstream git developers. git-new-workdir, however, is not supported and can cause problems if you try to check out the same branch in two working directories, etc.

Configuración

Prepare the first build on your disk just like explained above. For the second, and all other builds, do this to clone the initial core 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. You have to use an absolute path for the --with-external-tar option. After that, you proceed with building just like for the single-workdir case.
The --with-referenced-git option is only needed if you enabled some submodules (translations, dictionaries or help) or you're building the libreoffice-4-0 branch (or one that is even older). On newer branches submodules are disabled by default.
If you want to cherry-pick between the working directories, you can setup your local copy of git to act like a remote, like this:
You then just cherry-pick commits like you would to a "true" remote on another server.

Extracción de una rama de publicación de versiones

run autogen.sh on master with the specific parameters you need, then run make fetch to fetch the submodules that may be needed depending on the parameters you passed to autogen.sh
then switch branch with

No se encontró rpm/ant/paquete gnome-vfs-2.0

--disable-epm This will fix "rpm not found", as autogen.sh expects to find either dpkg or rpm on the system.
--without-java This will fix "ant not found"
As of the master towards LibreOffice 3.6, to build the UNO SDK you need to have Doxygen installed so that HTML documentation for the C++ UNO interface can be generated. One option is to install Doxygen from its website and make sure the doxygen executable is found on the PATH, or specify its exact location via --with-doxygen=pathname configure switch. Another option is to configure --without-doxygen, in which case the HTML documentation for the C++ UNO interface will be missing from the UNO SDK being built. A third option is to configure --disable-odk, in which case the UNO SDK is not built at all.
Note: Installing 'libgnomevfs2-dev' package on Ubuntu manually will fix "No package 'gnome-vfs-2.0' found" on older release branches. It should not be needed anymore on master by now. Use synaptic package manager or run in terminal

Crear paquetes DEB o RPM

If you are wanting to build DEB or RPM packages, this should do the trick...

RPM and DEB

RPM

DEB

¿Dónde están los paquetes?

Look for the files in the ./workdir/installation/ directory. There is a folder for each of the different sets of packages that includes subfolder[s] for the type or types of packages, either DEB, RPM, or both. Inside the subfolder[s] is another folder called install, and it includes two subfolders. One subfolder contains an archive of all of the packages zipped together (the ..._download folder) and the other contains a DEBS/RPMS folder with each individual package. The rest should be self-explanitory!

Dealing with line endings and Git's autocrlf

If autogen.sh produces output like the following:
... then you probably have line ending problems. This might occur if you mistakenly set Git's core.autocrlf=true.
To fix the issue, run these commands (WARNING: uncommitted changes will be lost!):

Building translated user interface with .po files from Pootle

La interfaz de usuario de LibreOffice se traduce mediante archivos .po alojados en el servidor Pootle. Las traducciones se actualizan y empaquetan en forma de paquetes lingüísticos con cada versión nueva que se produce, en todas las ramas. That often means language pack is not reflecting all the improvements made in-between releases and nightly builds exists only for a handful of languages. Translators might benefit from testing their work before new release been published and but early adopters could test translations before official release.
First make sure you managed build dependencies and then try to clone and run your build.

Compilar las traducciones de la interfaz de usuario

1. Firstly you need to download .po files from Pootle. You might log-in to Pootle to download .po files.
2. rebuild the source with language pack option on using command ./autogen.sh --with-lang="" and don't forget to replace with actual language code.
3. extract downloaded .po files and copy content to relevant directories in source tree using command (on GNU/Linux) cp -R /libo_ui/* libreoffice/translations/source// and don't forget to replace (two occurrences) with actual language code
4. this step might be tricky. Seams that some extracted .po files are named 'messages.po' and some are named differently. What you need is every .po file converted to .mo file and
   1. for files that are **not named** 'messages.po', conversion is done by running make build-l10n-only
   2. for files that **are** named 'messages.po' you need to convert to .mo files manually running msgfmt -o instdir/program/resource//LC_MESSAGES/ /messages.po for every such file. Here three things must be changed: to actuall language code, with data from left column of the table bellow and with data from right side of table bellow. Just make sure you prefix path '/messages.po' with full path from current working to destination.

As mentioned in step 4, some .po files are named 'messages.po' and some are named differently. Table bellow lists directories which might hold 'messages.po' files and on which step 4.2 should be applied.

acc.mo	accessibility
avmedia.mo	avmedia
basctl.mo	basctl
chart.mo	chart2
cnr.mo	connectivity
cui.mo	cui
dba.mo	dbaccess
dkt.mo	desktop
editeng.mo	editeng
filter	filter
for.mo	formula
fps.mo	fpciker
frm.mo	forms
fwk.mo	framework
pcr.mo	extensions
rpt.mo	reportdesign
sb.mo	basic
sc.mo	sc
sca.mo	scaddins
scc.mo	sccomp
sd.mo	sd
sfx.mo	sfx2
sm.mo	starmath
svl.mo	svl
svt.mo	svtools
svx.mo	svx
sw.mo	sw
uui.mo	uui
vcl.mo	vcl
wiz.mo	wizards
wpt.mo	writerperfect
xsc.mo	xmlsecurity

Last step in process is to run sudo make install to install with newly added translations.
If you would like to build LibreOffice-master and check the translation, you may need "make translations" to merge .po file with the .pot files.

Compilar las traducciones de los archivos de ayuda

Help files are also translated on Pootle so for translated Help file this can be done

1. by downloading .po files of translated Help
2. run ./autogen.sh --with-help --with-lang="" replacing with actual language code. If you want to build Help as HTML files, do --with-help=HTML.
3. run make
4. run cp -fR /libo_help/* libreoffice/translations/source//helpcontent2/source/text/, but remember to replace two instances of with actual language code and make sure you navigate to this folder correctly from current working directory
5. run mv libreoffice/translations/source//helpcontent2/source/text/auxiliary.po libreoffice/translations/source//helpcontent2/source/. Replace two instances of with actual language code and make sure you navigate to this folder correctly from current working directory
6. run make build-l10n-only
7. run sudo make install