- 1 Partition limitations
- 2 First Build
- 3 Rebuilds and partial builds
- 4 Checks
- 5 verbosity and debug builds
- 6 Some other useful commands you can use in the build system
- 7 Build system internals
It's known that building on FAT(32)-formatted partitions don't work (the error is "Permission denied").
The first time make is invoked, it will download the other git repositories needed (if any) and other external packages to be downloaded.
Building the product can take 8/number_cores hours on a reasonably recent processor, and much more on Windows.
$ ./autogen.sh $ make
Although this will do, you might want to do a little more typing with
$ make 2>&1 | tee build.log
This 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. Also with a fresh git clone, downloading and corresponding make might take some time. To avoid accidental killing of the process, one can use
nohup make as follows:
nohup make & which might nag
nohup: ignoring input and appending output to `nohup.out. Then you can check progress with
tail -f nohup.out.
If your build fails, check that you have satisfied the dependencies mentioned at the top of this page.
Rebuilds and partial builds
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.
$ make clean && make
Note that during the build process, absolute softlinks (with resolved links in the cwd) are formed inside the build tree. So if you want to duplicate compiled code, choose to preserve links or you will triplicate it instead (breaking the stuff). This, however, makes the copy attack the source when the copy is used/cleaned, so use a script that bends the links after such a copy.
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 also rebuild just that module.
$ make <module>.clean $ make <module>
make performs a number of checks (e.g. unit tests). That is a subset make check tests. There is a --build-nocheck switch that disables the checks when building. It may speed up the build considerably. However, it should definitely not be used when building for the first time, because otherwise you may miss a problem with your setup that will give you a build with strange behavior that nobody else sees.
verbosity and debug builds
If you want to get verbose output during build:
$ make verbose=t
Getting debug output
If you want to get the output of OSL_TRACE() calls and other debug messages:
$ make -s 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:
$ make -s ENABLE_SYMBOLS=true
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:
$ make -s clean $ make -s debug=true
When you want to build the debug version for a fix set of modules you can use:
./autogen.sh --enable-debug --enable-selective-debuginfo="<space separated list of modules terminated with '/' >"
The trailing '/' after each module is very important or no debug build is done!
Some other useful commands you can use in the build system
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.
For your first build, a lot of external tarballs get downloaded before the real build starts. If you want to build offline, you can do:
$ make fetch
before doing the build itself. 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.