Documentation/Building Guide/Building on MacOSX
This document tries to wrap-up the build process for OpenOffice.org on Mac OS X using the native windowing-toolkit of the platform named Aqua.
- 1 Prerequisites
- 2 Get the source and prepare to build it...
- 3 Doing the build (about 4,5 GB)
- 4 Installing, preparing and running OpenOffice.org
- 5 Contribute by finding, isolating, debugging or solving issues
- 6 Current Work in progress (Aqua specific work only)
- 7 Known build issues
- 8 External links
This document was derived from the description of the X11 build thanksworthy provided by Eric Hoch in this document: MacOSXBuildInstructions.
Here we would like to outline the things you need to build the Aqua Version (besides the OS).
- Mac OS X version 10.4 (aka Tiger) or later (if using 10.5 aka Leopard, have a look at User:Dyrcona/LeopardBuild#flex
- XCode version 2.4.1 or later. If you want to use a newer version that is shipped with your Mac OS X installation media, you need to register at the Apple Developer Connection site (free of charge) to be able to download it
Notes on Java: The Aqua version of OpenOffice.org does not build yet using Java SDK 1.6.0. If you didn't configure Mac OS X for a 1.6, you don't need to do anything - the default (1.5) is OK. To change the default Java version go to Applications/Utilities/Java and modify accordingly
Of course patches to make it build with 1.6 are very welcome :-) Feel free to submit your patches to the mac@porting mailing list or file issues.
If you intend to build OpenOffice.org several times, you probably can benefit of ccache since it will speed up your future builds. The first time you make a build with ccache you won't notice it, but the next time the build will go up to five times faster.
If you don't use fink, you can download and build it yourself using the source provided at http://ccache.samba.org/
There are two ways to enable ccache - one is to set environment variables, the other way is to use symlinks.
Using environment variables:
export CC="ccache gcc" export CXX="ccache g++"
Using the symlink approach:
# create a directory for the links mkdir ~/bin # create the symlinks pointing to ccache with the name of the compiler ln -s /path/to/ccache ~/bin/gcc ln -s /path/to/ccache ~/bin/g++ ln -s /path/to/ccache ~/bin/cc ln -s /path/to/ccache ~/bin/c++ # no all you need to enable ccache is to prepend ~/bin to your PATH $ export PATH=~/bin:$PATH
for both methody, you can add the "export ..." lines to your ~/.profile - that way you don't need to manually set it when building. You can still temporarily disable ccache (export CCACHE_DISABLE=1) in case you don't want to use it.
Since OOo is rather huge, you should increase the cache-size to 1 GB or more
ccache -M 1G
- subversion version 1.5.4 or later
Since OOo's source code is managed using Subversion currently, you also need the svn client to checkout sources (otherwise you would be bount to source-tarballs that aren't generated that frequently). You can either compile yourself or use the subversion universal 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 and prepare to build it...
Get the source from HG:
You need about 3GB for a checkout from the HG repository: The full source itself has about 1.6GB and HG needs another 1.5GB. Building the source requires another 5GB.
- check out the latest source from HG
hg clone http://hg.services.openoffice.org/DEV300/ ooo_source
Get the source from SVN:
You need about 3.2GB for a checkout from the SVN repository: The full source itself has about 1.6GB and SVN doubles that by its internal copy. Building the source requires another 5GB.
The directory name should not contain any spaces, otherwise building it might be troublesome.
- check out a milestone from SVN (if the milestone is older than DEV300_m63 and newer than DEV300_m31)
svn checkout svn://svn.services.openoffice.org/ooo/tags/DEV300_m46
- check out a an old ChildWorkSpace from SVN
svn checkout svn://svn.services.openoffice.org/ooo/cws/CWSNAME
- checking out milestones or ChildWorkSpaces from CVS (if they are older than DEV300_m32)
Have a look at the SVN for OOo documentation for more details, e.g. if you want to do complex tasks like merging several CWS into a single build
Additional dependencies for current milestone builds
prebuilt Mozilla archives (based on seamonkey1.1.13)
To enable the use of macros (disabled by default for security reasons), you'll have to put the prebuilt archives of mozilla binaries in moz/zipped directory after renaming them properly.
Note: archives are Intel only for now. UB will be proposed later
=> FIRST : apply the following patch to your tree : patch for moz2seamonkey zipped archives (else, you'll have a breakage in connectivity)
cp moz2seamonkey_connectivity.diff DEV300_m46 cd DEV300_m46 Fake the patch application : patch --dry-run -p0 < moz2seamonkey_connectivity.diff And if nothing wrong occurs, apply it for true : patch -p0 < moz2seamonkey_connectivity.diff
Archives to be downloaded :
- http://tools.openoffice.org/moz_prebuild/OOo3.2/MACOSXGCCIruntime.zip )
One-Time preparations and scripts
Work in progress: since DEV300_m42, config_office no longer exist, and what follows needs update, or might contain error(s)
OpenOffice.org's build environment is configured using the popular open-source configuration-management package 'autoconf'. So you can do your beloved './configure' command, is now done in the ROOt source directory. To save the configure parameters and use them with different milestones I used to link-in my shellscript to fire up the ./configure line.
My directory-structure looks like this:
bin/ DEV300_m42/ DEV300_m40/ DEV300_m0/ SRC680_m248/ ...
Now I go to the ROOT sources subdir and link in my startscript:
Create 'build.sh' (to be written) :
Note: excepted important changes in configure, this has to be done once only.
#!/bin/sh export BASE=`pwd` export OOVERSION=`echo $BASE|sed 's/^\/.*\///'` echo Building from : $BASE echo OpenOffice Version: $OOVERSION ./configure \ --with-lang="en-US de fr" \ --disable-odk \ --disable-pasf \ --disable-gtk \ --disable-headless \ --disable-build-mozilla \ --with-build-version=$OOVERSION-`date +%d-%m-%y` \ --disable-fontconfig \ --without-nas \ --with-jdk-home=/System/Library/Frameworks/JavaVM.framework/Home \ --with-stlport=no \ --disable-mediawiki \ --enable-werror \ --disable-vba
Put this script into ~/bin and make sure it is executable :
chmod ug+x ~/bin/build.sh
--disable-vba since CWS sb87 (was building by chance only)
--disable-mediawiki because ant version requirement to build the swext is now 1.7.0
--disable-odk : disables SDK build, and will avoid you to download some windows dll which is not needed for aqua-build.
--disable-pasf : pasf stands for Portable Audio System file. As we want to use system library rather than portable ones, we disabled this. However, at this time not all functionality will be available with pasf disabled. You might willing to use --with-pasf if you want working audio in your build.
--without-nas : nas stands for Network Audio System, it uses X11, if you want to use it in your build, just remove this flag. You will need to install the X11 package provided in your CDs/DVD Mac OS X installation. X11 SDK from xCode tools is not required for build this.
--disable-build-mozilla: will disable the mozilla build (in the moz module), but mozilla pre-built archives will be used instead (they are mandatory to enable the macro security configuration dialog (see Issue 79885 ).
--enable-dbgutil: add this option to enable assertions and other functionality useful for debugging
--with-jdk-home must be set as above with XCode 3.0
--with-stlport=no uses Apple's built-in STL, but will cause some warnings
We used the bash shell in all example, since to our belief users of the C-shell are smart enough to figure out the differences anyway. If you want to dig deeper into the build process, please have a look at the description OpenOffice.org's Build Environment.
Doing the build (about 4,5 GB)
Fine, now we have a (hopefully) working 'build.sh' in the ROOT sources dir. We need to run it beforehand:
link the existing build.sh with the current milestone :
ln -s ../bin/build.sh ./build.sh
Run it to complete the configure step :
This will setup the necessary includefiles and create a couple of files in the parent directory (bootstrap, MacOSXPPCEnv.Set.sh, MacOSXPPCEnv.Set). If you are using the sh, ksh or bash you only need to take care for 'MacOSXPPCEnv.Set.sh'.
Now we need to get back to our base-directory, run the bootstrap script, source our Enviroment (MacOSXPPCEnv.Set.sh) and finally start the build-process:
On Mac Intel
./bootstrap source MacOSXX86Env.Set.sh cd instsetoo_native export TMP=/tmp export SYSTEM_OPENSSL=YES
build --all -P4 --dlv_switch -link --dontgraboutput or build --all -P4
if you run into trouble with --dlv_switch (see: Issue 77360 )
./bootstrap source MacOSXPPCEnv.Set.sh cd instsetoo_native export TMP=/tmp export SYSTEM_OPENSSL=YES
build --all -P2 --dlv_switch -link --dontgraboutput or build --all -P2
Comments on above
if you run into trouble with --dlv_switch (see: Issue 77360 )
The main purpose of the bootstrap script is to build (if necessary) the dmake utility used. Dmake once was a unix make-clone made by wticorp but got incorporated into OpenOffice since it was orphaned. For more information about dmake, it's history and manpage have a look here: http://tools.openoffice.org/dmake/index.html
Sourcing MacOSXPPCEnv.Set.sh is very important not only for building but also for running svdem later on. Here all the Environment-Variables for the Build will be set up. For a detailed description see Environment_Variables. Please note that on Intel machines, 'MacOSXPPCEnv.Set.sh' should be substituted with 'MacOSXX86Env.Set.sh'.
This Build process takes on my box (Dual 1.8 GHz G5, 1.5GB RAM) roughly 10 hours, and 3 to 6 hours on Mac Intel (3:30h on a 2GHz DualCore INTEL iMac). Be patient.
If you want to see how the progress on that build is you can use two build options to get a comfortable view:
build ... <see above> ... --html --html_path /Users/$USER/Sites
where $USER is your user name. Then you can load in Firefox (not Safari!) the HTML file unxmacxi.pro.build.html via the in Mac OS X included Apache web server or diretctly form the directory /Users/$USER/Sites/. This file is automatically being updated and is showing the status of the build and also the time needed since the build started.
If you build on Snow Leopard (aka Mac OS X 10.6): Set DYLD_INSERT_LIBRARIES to point to the correct libsqlite3.dylib:
Installing, preparing and running OpenOffice.org
Find the Bundle
Once the build completed, the final product ( en-US version ) is named : OOo_3.0.0_*_MacOSXIntel_install.dmg ( for version 3.0beta e.g.)
And is located in instsetoo_native/unxmacxi.pro/OpenOffice/dmg/install/en-US directory ( replace en-US with your locale )
Install the new Build
- double click on the *.dmg icon
- drag the OpenOffice.org icon into a folder of your choice
Run the new Build
- double click the application icon in that folder
Now you can start to work with this amazing productivity suite.
Contribute by finding, isolating, debugging or solving issues
Isolate a problem
Reduce a problem
- make a problem reproducable
- reduce it to a test case that is as small and simple as possible
- if a problem is specific to a document then please attach it to the issue. A mininal excerpt of the document that still shows the problem is even better.
- a screenshot of is a good idea if it clearly shows the problem
Using application switches
Application switches are often valuable for isolating a problem. Most of OpenOffice.org's options can be found its Tools->Options menu.
Some switches are so special that there is no user interface to change them. They are only useful for debugging and isolating a problem, but they are very valuable a that. So a developer might suggest to isolate a problem by setting an environment variable before running the application. E.g. for isolating problems with the menubar a developer might suggest to set the environment variable AQUA_NATIVE_MENUS to false. This is done by typing these commands into a terminal:
- cd <INSTALL_DIR>/OpenOffice.org/Contents/MacOS
- export AQUA_NATIVE_MENUS=false
Provide a call stack for crash problems
Please note that bugs involving crashes should provide a description of how to reproduce the problem and a callstack. There are several ways to provide the callstack:
- the preferred method is to use OOo"s builtin crash reporting tool
- developers may provide a gdb backtrace of the problem
- if the above two methods don"t work then please attach a file with the details provided by the AppleCrashReporter
Check against known issues
Check the list of open issues
Report a new issue
Debug a problem
Debugging problems is often easier in an development environment:
Please note that XCode still has some problems with the executable named soffice.bin (because of the dot in the name). The issue has been reported to xcode-users list.
Current Work in progress (Aqua specific work only)
With OOO300 the Aqua port became a mainstream port, so most Aqua issues are handled in regular GSL-Layer childworkspaces instead of dedicated Aqua CWSses. Other CWSses that are purely Aqua specific are being tracked below:
- CWS DEV300 ogltrans4mac : Implement the 3D (OpenGL) transitions in Impress ( see : OpenGL transitions on Mac OS X )
Child WorkSpaces in development
- CWS DEV300 appleremote03 : use the contextual menu in presentation mode with Impress. preliminary step
- CWS OOO300 hotmac : fix memory deallocation problems in exit()
- CWS DEV300 macosxscanner01 (planned)
All patches that developers have that need testing or peer review should be added here.
Child WorkSpaces in testing (closed for development)
- CWS macmiscfixes : misc fixes for mac
- CWS maccrashrep : support crash reporting for OSX builds
- CWS quicklookplugin01 : a plugin for the QuickLook system available in MacOSX from versions 10.5 onwards
Child WorkSpaces waiting for integration
- CWS DEV300 appleremote02 : improve the Apple Remote use with Impress (use MEDIA_COMMAND stuff, improve code robustness, and portability )
Child Workspaces integrated into OpenOffice.org's trunk
A historical overview of old Aqua specific ChildWorkspaces.
Known build issues
- Tiger: no known issues
- Leopard: no known issues
- OpenOffice.org's Issuezilla : a database of bugs, changes and enhancements
- The porting mailing list is archived here. Send a "subscribe" mail to firstname.lastname@example.org to participate.
- Developers hang out on the freenode.org IRC in the #ooo_macport channel
- There are regular meetings on IRC (archives are available).
- OpenOffice.org has a complicated code base. Here is an overview.
- OpenOffice.org related blogs get aggregated on the OOo Planet
- OpenOffice.org's Environment Information System (EIS) tracks all details of the development progress
- Nakata Maho provides an invaluable package build service
- Cocoadev provides great resources to get up to speed in Cocoa development
- Pierre Chatelier's excellent Objective C for C++ developers is available in both english and french versions
- Details about OSX's Cocoa API are available in the XCode documentation