Building on Linux
- 1 Overview
- 2 Requirements
- 3 Full Builds
- 4 Partial Builds
- 5 Building a Module with Debug Information
- 6 Finding Installation Sets
- 7 Tips And Tricks
- 8 See Also
- 1 or more reasonable fast CPUs, x-way CPU's recommended.
- 1 GB Ram ( 2 GB recommended )
- at least 10 GB free disk space
- C/C++ Compiler:
- gcc >= 3.3
- gcc 4.2.3 is the current reference compiler
- The X11 development libraries and header files
- PAM including the development headers
- gtk2 and libtiff including the development headers
To perform a full build, you need to follow these steps:
The first time you have to run
autoconf to prepare a valid and up-to-date
configure script. And every time you make changes to the
configure.in script, the script will remind you to run
- Run the
configurescript to check all requirements. Run the following command to view all possible options.
An example configure command:
./configure --without-junit --disable-odk
See the last information box in the configure script or Category:Distribution-Specific_Build_Instructions for more information for your platform.
|Please check for any warnings emitted by the configure-script. The page OpenSolaris Build Instructions/Configure Errors may be helpful in debugging all the dependencies.|
When configure finished successfully, run:
to create the dmake executable required to build OpenOffice.org.
setting the environment
When the configure script has been run successfully a file
LinuxX86-64Env.Set.sh was created.
to set up the environment for the build.
starting the build
Build the software by typing the following in
cd instsetoo_native && build --all
The building procedure will take at least an hour (on a 3 GHz Quad-Core with 8GB RAM without CCACHE).
There are two ways to do partial builds:
Only do compatible partial builds if you know exactly what you are doing.
|For more information, see Compatible Builds.|
rebuilding from a module (incompatible build)
If you decide to change a module in an incompatible way, you will need to rebuild all modules depending on it (directly or indirectly):
cd $SRC_ROOT/instsetoo_native build --from $INCOMPATIPLEMODULE --prepare build --from $INCOMPATIBLEMODULE
rebuilding a module (compatible build)
To rebuild a module you can delete all output directories with, rebuild and redeliver into the solver with:
cd $MODULE build --from $MODULE --prepare build && deliver
$SRC_ROOT/instsetoo_native will recreate the installation sets, provided all other modules have already been build.
Building a Module with Debug Information
To rebuild a module with debug information and additional assertions and checks, run:
cd $MODULE build --from $MODULE --prepare # removes old output trees and solver build debug=true --from $MODULE
Drop the newly created binaries into an existing installation. Building an installation set with them will not help, as binaries are stripped on packing by default.
Finding Installation Sets
The english installation set will be located at
See also Run parallel versions.
Tips And Tricks
export CCACHE_DIR="some/place/with/space" ccache -M 2G -F 100000 export CXX="ccache g++" export CC="ccache gcc"
If you set the environment variable
TRUE, then dependency information files are not created - the build finishes faster.
|But only enable that on a clean build. Once you have built OOo and then made modifications, unset the variable again to be on the safe side.|
Similar to the
nodep variable, this one prevents the generation of HIDs (Help IDs) that are mainly used for automated testing - if you only want to build OOo, you don't need those.
If you have a multiprocessor machine or similar, you can run a parallel build. There are two levels of parallelism - one operating on makefile (directory) level, the other one on the global level. The two levels of parallelism result from the two-step build procedure in the OOo build environment. The build script runs through all the directories it reads from the build.lst files in all modules and calls dmake for every directory.
parallelism on the global level
For parallelism on the global level, you have to run build from
$SRC_ROOT>/instsetoo_native with the
-P<number> switch, for example:
This takes build how many dmake processes it is allowd to start in parallel.
parallelism on the directory level
export MAXPROCESS=<numer or processes>
This tells dmake how many targets it is allowed to build in parallel. When you don't use build.pl but build a single directory (single makefile), you can achieve the same with
combining both levels
If you want to have parallelism on both levels, you can call
build -P2 -- -P2
"--" is a special build.pl parameter that passes every further parameters to the dmake processes it starts.
Experience tells that using the doubled number of cores in your machine is a good choice, using more threads does not make a big difference, except if the combined option is chosen. So even on single core machines using two threads will speed up the build considerably.
create prebuilt mozilla
For the mozilla-components you have the choice to either build from mozilla sources, to use precompiled packages or to use system-mozilla (the one installed on your buildsystem, not everything might work, depending on the version you got installed). You can easily create your own version of the prepacked binaries if you wish to do so (either because you cannot use the official ones because of mismatch of compiler version used to build them/other technical reasons or because you want to use stuff you didn't build yourself). To do so:
- build the
mozmodule from the mozilla sources
--enable-build-mozillawhen running configure and put the mozilla-source tarball to
dmake zipto create the zip files
- you'll find the zips in
Copy them to a location of your liking.
Now instead of using
--disable-build-mozilla and copy the zips you created or downloaded to
moz/zipped and these will be used when compiling.
This will greatly reduce build-time (you save the time that would otherwise be spent on compiling mozilla).
- By default, native packages (.deb/.rpm) will be build.
build --allwould rebuild changed/missing files. However, it does not check for incompatible modules. If unsure, use
build --from --prepare.
- The en-US in the path names indicates that the localization is American English. This value corresponds to the language tags defined by RFC 1766 (Tags for the Identification of Languages). The German installation set will be located in a de subdirectory. This scheme holds true for all localizations you may have chosen explicitly.
Note that you can only build the language packs after you have build the complete office with all selected languages.
|Content on this page is licensed under the Public Documentation License (PDL).|