Building on Solaris
Introduction
Revised Building Guide: for Apache OpenOffice
Please Note: An updated version of the building guide, for Apache OpenOffice, can be found here.
Also see additional building information for the release you are building on the Developer_Snapshot_Builds page on the planning wiki.
Legacy Building Information
This page is archived for historical reasons only. It is no longer maintained and information may not be current.
Download as a PDF or ODT
Preface
Thank you for choosing to start building OpenOffice.org. It is a very interesting procedure and teaches you a lot about the source code and its structure.
This guide is the great first step if you are interested in modifying the source code, applying patches and fixes, or developing new features.
We hope that this document provides you with the information you need.
Getting help
If you experience problems on the way, please help us develop this guide!
- First subscribe to our dev mailing list by sending an empty email to dev-subscribe@openoffice.apache.org.
- Wait for a reply, respond to this email with an empty response.
- You get a WELCOME email saying you are now a subscriber.
- Send us a note at dev@openoffice.apache.org with your questions and problems.
- To unsubscribe from the list, send an empty email to dev-unsubscribe@openoffice.apache.org, wait for a reply, respond to this email, you get a GOODBYE email. You have now left the mailing list.
Content on this page is licensed under the Public Documentation License (PDL). |
Getting the source
Requirements
- Subversion version 1.5.4 or later
AOO's source code is managed in a subversion repository, so you need a svn client to checkout the sources. You can get subversion binaries from the subversion project. Version 1.5.4 or later is required because of important fixes related to the merge-feature.
Get the source via Subversion
You need about 4.7 GB for a checkout from the svn repository. Building the source requires another 5GB.
- check out the latest source from svn
svn co https://svn.apache.org/repos/asf/openoffice/trunk aoo
The directory structure when you have checked out the sources from svn will look like:
aoo/ aoo/main aoo/extras aoo/test/extras aoo/ext_libraries aoo/ext_sources
Content on this page is licensed under the Public Documentation License (PDL). |
Basic Concepts
To understand all concepts, techniques and the terminology described in this guide, make sure you understand the following basic concepts.
Contents
- 1 Introduction
- 2 Getting the source
- 3 Basic Concepts
- 4 Requirements
- 5 Building
- 6 Overview
- 7 Requirements
- 8 Installation and Preparation of Build Tools
- 9 Full Builds
- 10 Partial Builds
- 11 Building a Module with Debug Information
- 12 Finding the Installation Sets
- 13 Tips And Tricks
- 14 See Also
- 15 Overview
- 16 Requirements
- 17 Full Builds
- 18 Partial Builds
- 19 Building a Module with Debug Information
- 20 Finding Installation Sets
- 21 Tips And Tricks
- 22 See Also
- 23 Requirements
- 24 Solaris 11 Express
- 25 See Also
Terminology
Term | Description |
---|---|
SRC_ROOT | The environment variable containing the path to the directory of the source code. Example: /home/john/projects/ooo/builds/OOO310_m11 |
Branches
Development branch
The current development branch is located at:
http://svn.apache.org/viewvc/openoffice/trunk/
This is where most development is done. It has the most open policy for applying patches and it is typically where new features are developed and debugged.
The good side to this is that you have the latest features, the down side is that you get the side effects of the changes.
Stable branch, specialized branches
The latest stable release as well as branches that are used for development of some specialized aspect are located at:
http://svn.apache.org/viewvc/openoffice/branches/
A stable branch is base for a release build of the OpenOffice product. This is where bug fix tracking takes place. The policy on these branches are to fix functional errors only.
The good side is that any patches are more thoroughly vetted before going into a stable release. Therefore you have fewer mystery bugs. The downside is that there are fewer features and some bug fixes are already in the developer release.
Modules
The source code directory contains a lot of folders, each one representing a module. A module provides an application, a function, or simply just a collection of classes. A module is the smallest unit of the office suite that can be built.
Modules correspond to the directories under the top-level directory of the source tree. For example, the Writer project includes the sw, starmath, res modules, etc.
There are many dependencies between the modules, and the modules must build in a particular order. Module prerequisites are described in first line of the file prj/build.lst for example:
froddo: /data2/office/sw/prj$ cat build.lst sw sw : connectivity svx stoc uui sch NULL
We find that sw depends on connectivity etc. These modules in turn depend on others creating a large complex dependancy tree.
Build Styles
Full Builds
Developers typically perform a full build of OpenOffice in order to build their modules. A full build also recompiles all of the source code. It can take up to a few hours to perform a full build of OpenOffice.org even on modern workstations. However using tools such as distcc and ccache can have dramatic time improvements.
Partial Compatible/Incompatible Builds
To avoid the need of a time-expensive complete re-build each time a change in the code is introduced, the developers are asked to introduce only binary compatible changes in the code unless it is agreed with the project owner. This means that the changes made are of such a nature that no recompilation of further dependent modules become necessary (inserting a new, non-virtual method in a C++ class would be an example of such a binary compatible change). The office suite will then be re-compiled as a so-called respin build before the next 'master' s declared. A respin build obeys only weak dependencies, i.e. dependencies within a module. Using weak dependencies allows you to, for example, to modify a base library header file without needing to perform a full build. Since a respin build relies on binary compatible changes, modules can be build in parallel, and the build takes much less time (a few hours) in contrast to a full build.
By contrast, binary incompatible changes require a full build. For reasons of efficiency, this is allowed only with the approval of the project owner. |
Snapshots Builds
OpenOffice employs a buildbot for snapshot builds. However, the output of these builds are for developer use/information only. They are not advertised for public consumption -- beta testing. We follow Apache rules for the announcement of releases.
Source and Output Trees
OpenOffice.org developers work in parallel on all platforms. The source code for all platforms is identical, with the exception of the code for the interface to the operating system and window managers. This allows you to build for the different platforms simultaneously from a single source tree, i.e. the directory structure that stores all of the source code for the office suite.
The solenv
tree contains the environment tools that the build process uses, for all supported platforms. Formerly it also included the platform-specific build tools. Now these build tools are created with a bootstrap
script created with the configure
script.
When building multiple modules, these steps are taken for each module:
- The build process generates files from the source tree into the output tree of the module (this is a directory named after the platform, e.g. unxlngi6.pro for 32-bit Linux)
- After the module has been build, the results are copied to the solver, a directory sitting next to the top-level modules in the
SRC_ROOT
. This step is calleddeliver
(there is a tool with the same name). Modules cannot link/compile against the output directory of other modules, they only compile/link against objects in the solver.
When you run bootstrap
, the solver
directory is created. Initially, the solver
directory is empty. The build process populates this directory. The build process delivers all binary files, shared libraries, and dynamic link libraries to solver.
When you want to build a specific project, you only need the sources of the relevant SVN modules and the output tree solver
. You do not need the entire source tree, though typically a developer will check out one of the branches and build it from scratch.
For more information on the solenv and solver trees, see the Tools project. |
Content on this page is licensed under the Public Documentation License (PDL). |
Requirements
OpenOffice.org officially supports the following platforms.
System | Architecture |
---|---|
Windows | x86 |
Linux | x86, x86 64 |
Mac OS X | Intel |
Solaris | x86, SPARC |
General build requirements
Requirement | Description |
---|---|
Java JDK | Java implementation compatible with JDK 1.5 or JDK 1.6. OpenJDK is supported as well. |
Perl | Perl 5. For the regular build, Mdiles Archive:Zip (rpm:perl-Archive-Zip) and XML:Parser (rpm:perl-XML-Parser) are required. For committing changes to the repository, Crypt:SSLeay and SOAP:Lite are also required. |
CUPS | cups headers. Provided by a cups-devel package or a libcups2-devel |
PAM | PAM support. Provided by a pam-devel package or a libpam-dev |
Apache Ant | Ant 1.7 |
Archiver | zip and unzip |
gperf | gperf tool |
Mozilla1 | Some Mozilla libraries are needed. Choose one of the following: |
NSS4 | Mozilla build tools5 are needed for Windows. They can be obtained here. |
Notes:
- If you are a new developer, don't use the libraries. By using the --disable-mozilla switch for
./configure
, you waive the extra functionality. - Copy the package into $SRC_ROOT/moz/download. The
./configure
script will detect the source being present. - You have to configure with --disable-build-mozilla to enable the use of the prebuild libraries. Place LINUXGCCI{inc,lib,runtime}.zip into $SRC_ROOT/moz/zipped. The files can be reused if the packages were build following the instructions of the previous point. In the latter case, they can be found in $SRC_ROOT/moz/unxlngi6.pro of a successful build.
- The nss module will be introduced in DEV300m57. nss contains a subset of libraries from Mozilla (the moz module). They are supposed to be more current then those in the moz module. To prevent building nss and instead of using the libraries from the moz module, one can use the configure switch --disable-nss-module. This switch will be removed soon!
- Use the
configure
switch --with-mozilla-build to tellconfigure
where the tools are installed. For example: --with-mozilla-build=c:/mozilla-build
Platform specific requirements
Platform specific requirements are covered in each building instruction.
Content on this page is licensed under the Public Documentation License (PDL). |
Building
This page is archived for historical reasons only. It is no longer maintained and information may not be current.
Revised Building Guide: for Apache OpenOffice
Please Note: An updated version of the building guide, for Apache OpenOffice, can be found here.
Overview
For building OpenOffice.org Cygwin is needed, a Windows program that emulates a complete Unix commandline environment. To use this document you need to be familiar with a command line, but you need not to be a UNIX shell wizard.
If you have never used a Unix shell, you might want to take a look at the shell introduction at TLDP. |
You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases. |
Requirements
hardware requirements
- 1 or more reasonable fast CPUs (x-way CPU recommended)
- 1 GB RAM (2 GB recommended)
- 10 GB free disk space (20 GB when debugging)
software requirements
- Windows XP/Vista/7
The following table is placed here, so you can come back to it easily, when you want to use a link. The items are explained below. Here's the list of files to download (with links) and the locations in the source tree where you must put them:
Where to get | Place in/Use configure switch |
---|---|
Cygwin: Cygwin ToolKit with(dll version 1.5.10)or later | (default) |
C/C++ Compiler: free: Visual C++ 2008 Express Compiler(basic install, no optional required) offical: Visual C++ 2008 Professional | --with-cl-home= |
Windows SDK for Windows Server 2008[1] | |
Java: JDK 1.6 for DEV300 milestones >= m37 and all OOo310 versions (older milestones will fail in the hsqldb module) | --with-jdk-home= |
GDI+ Redistributable (Genuine Windows Validation required) | main/external/gdiplus |
dbghelp.dll[2]
Can also be found in the Visual Studio C++ 2008 Express installation. |
main/external/dbghelp |
Apache Ant (version 1.6.5 or later) | --with-ant-home= |
Mozilla binary distribution (WNTMSCIruntime.zip,WNTMSCIlib.zip,WNTMSCIinc.zip)
Needed as prebuilts for module moz (SeaMonkey) as the current used SeaMonkey version 1.1.4 does not support a build with Visual Studio C++ 2008 compiler. |
main/moz/zipped |
msvcr71.dll and msvcp71.dll for Mozilla libraries (Search for them in the Web or on your PC. These files should be named as all lower case. Sometimes when downloaded they are upper case and this will cause 'file not found' errors towards the end of the build)) | main/external/msvcp71 |
msvcp80.dll and msvcr80.dll for Mozilla libraries (found in c:\WINDOWS/WinSxS/x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd/msvc) | main/external/msvcp80 |
optional: Nullsoft Scriptable Install System (NSIS)[3] | |
optional: Microsoft DirectX SDK[4] | --with-directx-home= |
Legacy requirements that do not apply for Apache OpenOffice:
Where to get | Place in |
---|---|
not needed anymore for Apache OpenOffice |
|
not needed anymore for Apache OpenOffice |
|
not needed anymore for Apache OpenOffice |
|
not needed anymore for Apache OpenOffice . These merge modules are available in VS08 Express Edition and VS08 Professional Edtion. All *.msm files are located at c:\Program Files\Common Files\Merge Module. |
|
adding required files to the build tree
Some of the files can be found in a suitable OOo installation set also, so you can save the download by “stealing” it from your OOo installation. |
The default cygwin version offered on http://www.cygwin.com/ now is 1.7.x. For current milestones it is recommended to use this version as it fixes the .dll remapping problem (see below) and is required for builds on Windows 7. If you need to build old versions of the source code, check out http://www.cygwin.com/win-9x.html |
Installation and Preparation of Build Tools
setting up cygwin
Go to http://www.cygwin.com/ and download and install the current version.
Make sure that the PATH variable in your cygwin shell does not contain any blanks and quotes, otherwise configure will not work |
required additional packages
Cygwin consists of some basic and a lot of optional packages. As building OOo needs some of these optional packages you have to select them in the installer. Here's a complete list of the needed packages:
- Category Archive:
- unzip
- zip
- Category Devel :
- autoconf
- bison
- flex
- gcc-g++
- gperf
- make
- openssl-devel (only needed for perl modules for CWS tooling, see below)
- mercurial (or cvs for 2.x-3.0, or subversion for 3.1 codeline)
- readline (may be libreadline7 under Base category in newer versions)
- Category Libs
- openssl
- Category Net
- openssh
- Category Perl
- perl
- Category Shells
- mintty
- Category Utils
- patch (may be under Devel category in newer versions)
- gnupg
- Category Web
- wget
The installer will automatically check and download some more packages needed by thosed listed here. The whole process takes roughly 20 minutes. |
breaking links to executables
Within the Cygwin Toolkit, some executables might be symlinks: awk.exe and gunzip.exe, tar.exe (in older releases only). This can lead to a break of the build later, and the symlinks should be replaced by copies of the command they link to.
To check this, execute:
ls -l /bin/awk.exe
whether e.g. awk.exe is a symlink. In version 1.5.24-2 awk.exe is a link to gawk.exe. The shell will show this by putting out “awk.exe -> gawk.exe”. In this case gawk.exe must be copied to awk.exe by executing:
cd /bin rm awk.exe cp gawk.exe awk.exe
In case you overlook something here or you have a newer Cygwin version with additional symlinks not mentioned here it's not a problem. You will get a helpful error message about an existing link in the configuration step (configure) later. The message will tell you which link you have to remove and you can do it following the advice given above for the awk.exe/gawk.exe pair.
installing additional perl modules in cygwin
As explained some perl modules must be installed with CPAN. The necessary command in the cygwin shell is
perl -MCPAN -e shell
If this command is executed the first time CPAN will ask for configuration. Choose autoconfiguration.
At the end the CPAN shell appeared and is ready to accept commands for installations. Each module is installed by typing install $MODULENAME
. The modules that must be installed are:
- Archive::Zip
- LWP::UserAgent
not needed anymore for Apache OpenOffice
- XML::Parser (though it seems that this is already installed; doesn't hurt to do it)
- Actually the build process still seems to require XML::Parser? I was just doing my first build on Windows 10 today and I received the error message that this module was needed along with the expat module that it depends upon... I had to install "expat" in the Cygwin setup Johnrdorazio (talk) 21:30, 14 September 2016 (UTC)
- URI
- Crypt::SSLeay
- SOAP::Lite
CPAN will detect if a selected module depends on other modules and it will offer to download them also. As explained please just confirm this.
The last three modules are only needed if you want to use the cws tooling. These tools are necessary if you want to create and maintain your own Child Workspaces or if you want to build one of them. I recommend to install them anyway as sooner or later you want to work on a child workspace. |
Full Builds
configure
Finally the configure
tool is used to create the environment. It checks that all software, hardware, and system requirements for the build are satisfied, and creates configuration files called winenv.set (for tcsh) and winenv.set.sh (for bash) that are used to set all necessary build environment variables. Before running configure, make sure that all needed programs are in the system path or start configure with the appropriate command line switches. If configure detects a problem it will stop and give you a useful hint how to fix it.
For building OOo from the Mercurial repository:
You will find the configure
script in $SRC_ROOT
. The resulting configuration files are created there too.
For building OOo from the Apache svn repository:
call autoconf
in $SRC_ROOT
. This will create the configure step. Repeat that and the configure step after each change in configure.in (either by yourself or anyone else).And every time you make changes to the configure.in
script, the script will remind you to run autoconf
again.
autoconf
sample configure calls
You can get short explanations for all parameters by using ./configure --help.
minimum (requires the most prerequisites) - pathes of course are machine dependent:
./configure --disable-build-mozilla --with-mozilla-build="/cygdrive/d/OOo/mozilla-build-1.3" \ --with-cl-home="/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC" \ --with-mspdb-path="/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/Common7/IDE" \ --with-frame-home="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1" \ --with-psdk-home="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1" \ --with-midl-path="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v6.1/Bin" \ --with-asm-home="/cygdrive/c/Program Files/Microsoft Visual Studio 9.0/VC/Bin" \ --with-csc-path="/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5" \ --with-jdk-home="/cygdrive/c/j2sdk1.5.0.06" \ --with-directx-home="/cygdrive/d/OOo/DirectXSDK" \ --with-ant-home=/ant \
some further settings that might help to get rid of some prerequisites that not every developer needs (but be aware, this will also remove some parts from the final build result):
--disable-mozilla \ --disable-activex \ --disable-directx \ --disable-atl \ --without-junit \ --disable-binfilter \ --disable-odk \
for all builds on code lines older than OOo330 or older than milestone m77 on the DEV300 code line:
--with-use-shell=bash
some other settings worth considering:
--enable-pch \ --enable-werror \ --enable-dbgutil \
in case you want to have several workspaces on your hard disk, it might be a good idea to share external source tarballs:
--with-external-tar=d:/OOo/ext_sources \
configure settings tips
Paths to dependencies might be different for your installation. The pathes containing "msvc" and "msdk" should be self-explanatory. |
There are a number of options that you can use with the configure script. To display these options, type the following command:
./configure --help |
{{Warn|If you run into problems compiling on an "Express Edition" (such as Cannot open include files: 'atlbase.h': No such files or directory), check your settings in winenv.set.sh for DISABLE_ATL
, DISABLE_ACTIVEX
: all have to be set TRUE
. Visual Studio Express compilers do not contain everything needed to build the OOo ActiveX control, OLE automation and native Windows OLE support, so either disable support for them via --disable-atl --disable-activex
or add them via the WDK.
csc.exe comes from the c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 directory, you might need --with-csc-path .
|
If you fail to getting together a working installation of Cygwin, one possibility is to use a known-to-work combination of Cygwin packages, i.e. a direct copy of some other user's Cygwin tree. User:TorLillqvist has such a tree (from late 2006) zipped up at http://download.go-oo.org/tstnvl/tml/tml-cygwin.zip . Don't hesitate to ask for advice if necessary. |
bootstrap
After running configure you must create the dmake make utility that is needed for the build of OpenOffice.org. This done from the SRC_ROOT directory by calling
./bootstrap
setting the environment
When the configure script has been run successfully a file winenv.Set.sh
was created[7]. Do this:
source winenv.Set.sh
to set up the environment for the build.
starting the build
Build the software by typing the following in $SRC_ROOT
[8]:
dmake
The building procedure will take at least an hour (on a 3 GHz Quad-Core with 8GB RAM).
There are some special things in the way how OOo builds its modules. Every module has an “output” folder (with some subfolders for the different kinds of generated output) that is created the first time a build is done in the module. The name of this folder is “wntmsci10.pro” for builds with MSVC++2003, “wntmsci11.pro” for builds with MSVC++2005 and "wntmsci12.pro" for builds with MSVC++2008 (for the meaning of the "pro" extension see below). After a successful build of a module some of the generated files are copied to the output folder of the “solver” module by executing a tool called “deliver” (this is automatically called by build --all for each of the modules). Other modules will take these “delivered” files (header files, libraries etc.) to resolve their dependencies. The content of the solver module will also be used to pack the installation sets in the final step.
Using some not quite latest cygwin releases (1.5.18/1.5.19) can lead to tcsh freezing in places - the build will appear to hang. You can fix this by running ls /proc/$nnn/fd where $nnn is the number of the process. Or just run
ls /proc/*/fd to "unhang" the process. See Issue 51560 for more info... |
Partial Builds
There are two ways to do partial builds:
- compatible
- incompatible
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
A simple build
in $SRC_ROOT/instsetoo_native
will recreate the installation sets, provided all other modules have already been build.[9]
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.
For details, see Windows Debugging. |
Finding the Installation Sets
After a successful build you will find the OOo installation set in
instsetoo_native/wntmscixx.pro/Apache_OpenOffice/msi/install/en-US
“instsetoo_native” is the module that packs the installation set.
If you already have a version of OOo installed you can install your freshly built version in parallel by installing it with setup /a that just unpacks all files without any system registration. See Running in parallel. |
Tips And Tricks
ccache
For Windows: download from here, do the following:
export CCACHE_DIR="some/place/with/space" ccache -M 2G -F 10000 export CCACHE_CPP2=TRUE export CXX="guw.pl ccache cl" # export USE_PCH= if you experience trouble with precompiled headers
dependencies
nodep
If you set the environment variable nodep
to TRUE
, then dependendy 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. |
NO_HIDS
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.
parallel builds
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:
build -P2
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
dmake -P2
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.
Recommendation
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
moz
module from the mozilla sources - use
--enable-build-mozilla
when running configure and put the mozilla-source tarball tomoz/download
- in
moz
rundmake zip
to create the zip files - you'll find the zips in
{platform}.pro/zipped
Copy them to a location of your liking.
Now instead of using --enable-build-mozilla
, use --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).
See Also
- ↑
This also supported on Vista. This is either a DVD image or a net installer. You can either mount the DVD with a suitable tool, burn it do a DVD or use tools like winrar that can extract files from ISO files directly. You don't need to install samples or documentation (saves a lot of disk space). It will also install the .NET Framework 3.5 SDK. It might be best to install the Windows SDK into the default directory, and if not that into one without capital letters in the path. I used D:\Dev\Win_SDK\ and received some linking errors in the Python module (see Issue 88568 ).
- ↑
- ↑
If NSIS is available, a self contained Windows installer is created in addition to the MSI installer files. It used to be that newer version of NSIS broke the build (see Issue 85657 ), but it seems that it now works for NSIS up to 2.3.7. - ↑
If you don't want to download it you can disable DirectX support in the configuration step ( --disable-directx
).Current (as of 2008/01) versions of the DirectX9 SDK and Windows Platform SDK do not fit to each other. To be able to build with DirextX enabled, you need to patch one file in the Platform SDK. See http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID2743771 for details. - ↑
- ↑
- ↑
- ↑
- ↑
Content on this page is licensed under the Public Documentation License (PDL). |
The latest build instructions can be found under the Apache OpenOffice Building Guide and we are trying to improve the documentation continuously. If you run into trouble and find problems please let us know. We appreciate every kind of feedback that help us to improve the usability of our source releases. OpenOffice is a very huge piece of software with many external dependencies but these build requirements have to be collected only once.
Older build instructions are kept for convenience for users who still want to build older sources.
For the old build instructions for OpenOffice.org, go straight to AquaBuild.
If you're looking for information on how to build old versions of OpenOffice.org that still require X11 to run, head to Mac OS X Build Instructions (X11)
Overview
You are advised to check the release notes for the release you are building to inform yourself about changes since previous releases. |
Requirements
hardware requirements
- 1 or more reasonable fast CPUs, x-way CPU's recommended.
- 1 GB Ram ( 2 GB recommended )
- at least 10 GB free disk space
Software requirements
The most recent information for building on specific Linux distributions can be found at:
Historical (outdated but perhaps useful) information on distribution specific packages can be found from the Distribution specific build instructions pages. Included distributions are: |
- C/C++ Compiler:
- gcc >= 3.3
- gcc 4.2.3 is the current reference compiler
- The X11 development libraries and header files[1]
- PAM including the development headers[2]
- bash.
- gtk2 and libtiff including the development headers[3]
Full Builds
To perform a full build, you need to follow these steps:
autoconf
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 autoconf
again.
autoconf
configure
- Run the
configure
script to check all requirements. Run the following command to view all possible options.
./configure --help
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. |
bootstrap
When configure finished successfully, run:
./bootstrap
to create the dmake executable required to build OpenOffice.org.
setting the environment
When the configure script has been run successfully a file LinuxX86Env.Set.sh
or LinuxX86-64Env.Set.sh
was created[4].
Do this:
source LinuxX86Env.Set.sh
or
source LinuxX86-64Env.Set.sh
to set up the environment for the build[5].
starting the build
Build the software by typing the following in $SRC_ROOT
[6]:
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).
Partial Builds
There are two ways to do partial builds:
- compatible
- incompatible
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
A simple build
in $SRC_ROOT/instsetoo_native
will recreate the installation sets, provided all other modules have already been build.[7]
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.
For details, see Debugging. |
Finding Installation Sets
The english installation set will be located at $SRC_ROOT/instsetoo_native/unxlngi6.pro/OpenOffice/{deb,rpm,archive}/install/en-US/
[8].
See also Run parallel versions.
Tips And Tricks
ccache
export CCACHE_DIR="some/place/with/space" ccache -M 2G -F 100000 export CXX="ccache g++" export CC="ccache gcc"
dependencies
nodep
If you set the environment variable nodep
to 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. |
NO_HIDS
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.
parallel builds
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:
build -P2
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
dmake -P2
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.
Recommendation
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
moz
module from the mozilla sources - use
--enable-build-mozilla
when running configure and put the mozilla-source tarball tomoz/download
- in
moz
rundmake zip
to create the zip files - you'll find the zips in
{platform}.pro/zipped
Copy them to a location of your liking.
Now instead of using --enable-build-mozilla
, use --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).
See Also
- ↑
- ↑
- ↑
- ↑
- ↑ By default, native packages (.deb/.rpm) will be build.
If you want to have something faster and easier to test:
export FORCE2ARCHIVE=true
This will create a tarball that can easily be unpacked and run anywhere. An alternative is to set
export PKGFORMAT=installed
which will create a runnable installation in the output directory of instsetoo_native (Dont set LOCALINSTALLDIR on older milestones, see Issue 111450 .
- ↑
- ↑
- ↑ 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.
Running the configure script with the --with-lang option will introduce the build of additional language resources. This switch accepts one or more RFC 1766 language tags as arguments. Check the value of the completelangiso
macro in$SRC_ROOT/solenv/inc/postset.mk
for all the currently supported language tags.
Example:
./configure --with-lang="de fr"
This enables the build of the localized German and French version. The environment variable
WITH_LANG
will then contain the language tags of the additional (en-US will always be built) languages.
Content on this page is licensed under the Public Documentation License (PDL). |
This document describes building OpenOffice.org on Solaris.
Requirements
Hardware Requirements
- Solaris/x86: one or more reasonable fast CPUs, x-way CPU's recommended.
- Solaris/Sparc: UltraSparc III
- 2 GB RAM
- 10 GB free disk space
- if you don't have a lot of RAM (less than 4GB?) set TMPDIR to a directory that is not on tmpfs
Software Requirements
- Solaris 10, OpenSolaris 2008.5 or higher, Solaris 11 Express
- C/C++ Compiler: SunStudio 8, SunStudio 10 - SunStudio 12, SunStudio Express, newer compilers will likely work but may require a little tweaking (but rumor has it that 12update1 breaks on some boost stuff)
- the new build system currently only supports SunStudio 12, so older versions won't work on current DEV300/OOO340.
Solaris 11 Express
This section describes building on version snv_151a
.
Note that only DEV300_m106 or newer contains the necessary fixes in the OOo code.
Prerequisites
You need to pkg install
at least the following additional packages:
- mercurial (to get at the source code)
- system/header
- header-math
- developer/java/jdk
- developer/java/junit
- developer/build/ant
- developer/gperf
- developer/gnome/gettext
- developer/parser/bison
- developer/lexer/flex
The only dependencies that are not in the Solaris Express repository are the SunStudio compiler and the Perl module Archive::Zip
.
To install the Perl module, use CPAN (i'm afraid you need to su to root to do this):
# PATH=/path/to/sunstudio/SUNWspro/bin:$PATH /usr/perl5/bin/perl -MCPAN -e 'shell' cpan> install Archive::Zip cpan> exit
Building OOo
It is necessary to put SunStudio on the path, otherwise the build will break in stlport.
Also, set the CC
and CXX
variables.
PATH=/path/to/sunstudio/SUNWspro/bin:$PATH ./configure CC=/path/to/sunstudio/SUNWspro/bin/cc CXX=/path/to/sunstudio/SUNWspro/bin/CC
Building with --enable-werror
should work with SunStudio 12.
If configure runs successfully, the build should work just like on other platforms.