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.
- 1 Ubuntu Intrepid
- 2 Suggestions
- 3 Creating your own Virtual Machine
- 3.1 VirtualBox Settings
- 3.1.1 Memory
- 3.1.2 Hard Disks
- 3.1.3 Stuff you cannot do from VirtualBox GUI
- 3.1 VirtualBox Settings
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
- 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
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.
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 :-)
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.
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
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.