It is four months since I last posted on this one: Terry’s Adventure in Build OOo — Part I . OK a big part of the delay has been heavy work commitments, but what an uphill learning experience this has been. I spent a couple of months trying to get to the point where I could build OOo. My starting points were the OpenOffice tools page Building OpenOffice.org 2.x (680er series) under Linux and the Wiki article Building OpenOffice.org and related articles. From these I could see that there are two approaches: an “official” build process as referenced on the OpenOffice site and the alternate “ooo-build” process as well. As I said in the first part of this article, I built my system using an openSUSE release. My first thoughts were to try to follow the official process working as near as possible “out of the tin”, using the solver tree. Downloading the source and solver tarballs and setting up an OOC680_m7 project tree is straight forward. Working though loading all the dependent packages is a tedious case of trial end error, since the consequence of missing packages is that part way through the build, the make barfs. However, I eventually got to building then delivering the updates into the solver tree. Now it was simply a case of doing a soffice -calc, isn’t it? Nope, all I get when I did this is blank (that is with no message at all) OK dialog box. Searching the Internet here gives no clues. Time for a new tack, and at this stage I also decided to switch to a VM and so tried a preloaded openSUSE appliance with VMware player. (BTW one of the nice advantages of this is that you can easily use Winzip or whatever your favourite archive tool is to checkpoint your full development at critical stages. Its also trivial to move the environment from machine to machine.)
The only problem was that this openSUSE appliance was a split 4+4 Gbyte (system and home partitions) and neither was big enough. At this stage I wondered if the platform sensitivities had anything to do with it, so I decided to switch to an Ubuntu VM. This had two advantages. The first was that it had a single 8 Gbyte combined partition for the system and home directories . The second was that I found that I preferred Ubuntu’s leaner look and feel. The whole Ubuntu vs. openSUSE issue merits a debate in its own right. OpenSUSE is an incredibly polished package with everything nicely integrated in it, but I found it annoying to be spoilt for choice: 3 browsers; 5 terminal packages, … I feel that if I were to replace my standard WinXP platform then I might well go with openSUSE, but for a test bed, Ubuntu is a fine choice. The only fly in the ointment here was that 8Gbyte partition proved to be too small, so I ended up increasing this to 12Gbyte which is fine. See Building a VMware Appliance Playpen for a description of how I build this system.
Back to building OOo. In my experience the best approach to most problems is RTFM , but in this case the manual doesn’t seem to exist, and I did try hard to look for one honest . The main challenge is that there about a few hundred options to the OOo configure command and some are mandatory and / or must be disabled depending on your particular OS build. The only problem is that you are just expected to know, and if you don’t then tough. At this point I turned to the ooo-build framework, which I might describe in retrospect as OOo hacking for normal mortal developers. Since I was starting with an Ubuntu playpen, the OpenOffice Wiki gave a good starting point in its Ubuntu Build Instructions. Moreover when you take apart the ooo-build process you discover that it is basically a wrapper around the standard build with a whole raft of configuration options that are specific to your distro and a whole bunch of patches many of them distro-specific and needed to make soffice run on your OS build. Even so it still took some trail and error to make the build sequence work. Here is my modified version that I actually used.
#!/bin/bash # # This first bit needs to be run under su. I normally adopt a strict minimalist approach # to using su, but what the hell -- after all this is a playpen. # # Also note that before I ran this I went into Synaptic Package Manager (the nice GUI # version of sudo and remove the default Ubuntu install of OOo and Ubuntu Desktop. Not # sure whether this was necessary but I just wanted to make double sure that I was # building a clean OOo # #sudo apt-get -y install cvs automake1.9 build-essential libpam0g-dev libpng12-dev flex \ bison libgtk2.0-dev \ tcsh libcupsys2-dev java-gcj-compat-dev libarchive-zip-perl \ libjpeg62-dev libxml2-dev python-dev libdb4.3-dev \ libdb4.3-java-dev libcurl3-dev \ unixodbc-dev libldap2-dev mozilla-dev libnss-dev libsane-dev libxaw-headers \ libaudio-dev libsndfile1-dev libneon24-dev libgnomevfs2-dev libstartup-notification0-dev ant # note that this does prompt for a (blank) password so you need to hit an # extra CR before you can leave this unattended export CVSROOT=':pserver:anonymous@anoncvs.gnome.org:/cvs/gnome' cvs login cvs -z3 co -P ooo-build cvs up -Pd -r ooo-build-2-0-4 echo "Preparations complete." cd ~/ooo-build ./autogen.sh --with-distro=Ubuntu --disable-kde --disable-mozilla \ --with-jdk-home=/usr/lib/jvm/java-gcj --disable-gtk --disable-cairo --disable-gstreamer ./download # Now comment out failing patch: Note that ubuntu-dictionary.diff no longer fails, # However, build-java-target.diff does cp patches/src680/apply patches/src680/apply~ sed 's/^build-java-target\.diff/#&/' <patches/src680/apply~ >patches/src680/apply rm patches/src680/apply~ # Some of the source path in neon from the default include path. In Ubuntu it is # in the neon subdirectory. It was much easier to do the following than extend th # include search list. (We're in a sandpit VM afterall if ! test "/usr/include/ne_207.h" ; then cp -t /usr/include /usr/include/neon/*.* ; fi make
This was an overnight job on my PC. Note that I also didn’t bother with CCACHE. What this does is to speed up dumb makes by detecting when C or C++ is being asked to recompile a source that it’s already done before with the same options. What this can do is if you are doing complete rebuilds the it can cut the remake time right down from 12hrs to a couple. However it doesn’t help one iota if you are just going to do a once through to create your own solver and then hack in a single subsystem. Here make is usually smart enough to get it right.
The last step is to install the build into a distribution directory (Note the use of the -l option so that components symlink back into solver) and to change the ownership back to Ubuntu — that way you can do your routine hacking in a user account rather than root:
bin/install -l /opt/ootest chown -R ubuntu:ubuntu /home/ubuntu chown -R ubuntu:ubuntu /opt/ootest
Now that you’ve set up a standard OOo development environment within the ooo-build environment, you can hack individual subsystems by
cd ~/ooo-build/build/OOO_2_0_4 source L*.sh cd basic build
The easiest way to start up OOo at this point is to use a dedicate command window (that way you can hack log output to stdout) and use the command. By doing this from the hacking subsystem, soffice will automatically path in you build shares etc.
cd ~/ooo-build/build/OOO_2_0_4 source L*.sh cd basic/opt/ootest/bin/soffice.bin
What I’ve done with this environment is now the subject of later discussions.