Prepared Build Images

Building OpenOffice.org can be a challenging task not only for people new to the build process. With a prepared machine it is easier to get a build environment running and therefor people can start contributing to project faster without the obstacle of building.

Here is a list of virtual machine images that contain a complete and ready to start OOo build environment. If you have prepared such build environment on a free operating system, feel free to add it to the list here.

Ubuntu Intrepid

This harddisk image for VirtualBox contains a complete Ubuntu operating system, all necessary prerequisites and the sourcecode of the developer milestone DEV300_m35.

• Download and install VirtualBox
• Download and extract the VDI image (could take some time, the extracted image is 16 GiB large!)
• Create a new VM in VirtualBox with at least 512 MiB RAM
• Add the VDI image as boot disk to the created VM
• Boot it and have fun!
• If you need help read the README file on the Desktop and post your question to one of the mailing lists

Download via BitTorrent 1.4 GiB

Suggestions

• Dynamically growing harddisk images
• Scripts for simplified packaging and installation
• More --disable switches for faster builds
• Baseline environments
• More Linux flavours

Creating your own Virtual Machine

As preconfigured VMs with a complete set of sources and buildtools tend to get outdated very soon, the following way will illustrate how you can create an up-to-date version. The sample uses Mandriva, but the VirtualBox methods layed out here should work for all Distro flavours

VirtualBox Settings

Building in VirtualBox of course offers better performance if your host-CPU offers hardvare virtualisation support, but that is not a requirement. So enable all hardware acceleration feature your Hardware supports (esp. VT-x/AMD-V and Nested Pages)

Audio is not needed to build, so disable Audio (and also serial devices)

The following should give you an overview of suggested settings for your VM.

Memory

Thankfully, building OOo doesn't require much RAM, so 256 MB are enough to build (with a corresponding swap partition. On 64bit guests however, you should use 512 MB If you can spare more, then assign more of course :-)

Hard Disks

Create (at least) two harddisks - one for the Linux system, and one for all the build files

this allows you to re-use the build files with other VMs, and makes it easy to replace the guest distro or reinstall it.

i SATA controllers cause less overhad, so assign the disks to a SATA controller

Disk space requirements:

• The tools/libraries to build OOo (and the linux base system) require less than 2GB on disk, plus an additional swap-partition however you should create a significantly larger disk for the system (just set it to dynamically growing).

  4 GB (suggested Minumum), 8 GB (recommended)

• The build-disk needs to be significantly larger - it needs to hold the sources, the build-tree, and ccache. Following numbers all rounded up to nearest GB
  • Mercurial sources (repo-only, no checkout) + ext_sources: ~3 GB
  • build directory (ony checkout, no repo, after a build): 7 GB (thus if you use clone instead of archive, you need around 10GB for a build (+temporary diskspace)
  • ccache: Depends on your usage requirements. When building lots of different cws and milestones (tinderbox use), consider assigning 8GB (or even more). If you build mainly one cws at a time, only use one base-milestone at a time, 1 GB to 2 GB are enough

  Total: You should create a 20 GB (or larger) harddisk

Create two Harddisks for your VirtualMachine a system disk with at least 4 GB (8 GB if you also want to install a graphical environment) a data/build disk with at least 20 GB

Stuff you cannot do from VirtualBox GUI

Unfortunately you cannot do all the configuration in the VirtualBox GUI application, for some more advanced configuration taks, you have to use the VBoxManage command from the console/terminal.

Port forwarding for ssh-access to the box when using NAT-Network

Of course only needed when you want to ssh into the guest instead of using the VirtualBox GUI. I find using ssh a lot more comfortable, and furthermore using ssh is the only way to talk to your guest when you use VBoxHeadless to start your virtual machine without UI

With older versions of VirtualBox you had to set custom properties like the following to forward local port 2222 to port 22 in the guest:

VBoxManage setextradata "Mandriva" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP
VBoxManage setextradata "Mandriva" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22
VBoxManage setextradata "Mandriva" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222

It should be pretty self-explanatory.

• "Mandriva" is the name of the Virtual Machine to modify,
• "pcnet" is the type of network adapter you configured your VM with - replace with "e1000" or "virtio-net" depending on what card is configured.
• "LUN#0" for network adapter number 0
• "guestssh" is an identifier, you are free to choose any name here

Current versions of VirtualBox store this in a different way:

VBoxManage modifyvm "Mandriva" --natpf1 guestssh,tcp,,2222,,22

• "--natpf1": configure NAT portforwarding for adapter number 1 (1 based)
• "guestssh,tcp,,2222,,22": guestssh is again a free-to-choose identifier, tcp specifies the protocol, the omitted parameter is an optional host-IP, 2222 is the host port, the second omitted parameter is an optional guest-IP, 22 is the guest

Advanced hypervisor features: Large-Pages and VPID support / exclusive access

If your host supports it, then also enable large-pages support and Virtual Process Identifiers

VBoxManage modifyvm "Mandriva" --largepages on
VBoxManage modifyvm "Mandriva" --vtxvpid on

refer to the VirtualBox Manaual for details

Similarly enable exclusive access to hardware virtualization layer, unless you also use other hypervisors

VBoxManage modifyvm "Mandriva" --hwvirtexexcl on

Adjusting Clock settings

In case you're using hardware virtualization, and time in the guest is drifting significantly compared to the host's clock ("hardware clock", as system time gets updated regularly by the guest additions), you might need to change the Time Stamp Counter settings to real execution time (compare VirtualBox Manual):

VBoxManage setextradata "Mandriva" "VBoxInternal/TM/TSCTiedToExecution" 1

Not doing so can cause all kinds of timer related errors, from simple application timeouts to controller hickups)

Setting a flush limit for virtual disks

Only needed in case you got problems with the guest's AHCI controller (usually only hit when running multiple VMs at the same time and/or when the host has poor write performance): Set a flush limit to reduce possible delays when accessing the virtual disk. This is a tradeoff between performance and reliability. Refer to the VirtualBox manual for details.