Ubuntu Build in a VMware Appliance

From Apache OpenOffice Wiki
Revision as of 12:24, 25 August 2007 by TerryE (Talk | contribs)

Jump to: navigation, search

BUILDING OOo 2.2.1 over a Ubunt 6.10 (Edgy) VM

Background

This tutorial provides a simple cookbook to create a simple portable OOo development environment based on the primary author TerryE's experiences. It rolls up an output following various false start and permutations, which was based on the following parameters:

  • Which code-base to use? A previous playpen work was on Ubuntu on an OOo 2.0.2 build doing some bug hunting. This was based on the Ooo-build described [Ubuntu_Build_Instructions]], which really helped me get up and running a lot quicker. However, the difficulties arose when I started to make changes or hunt bugs. Was the code that I was looking at base OOo code or something that the VBA project etc. introduced? So I decided to use the standard OOo kit as my future baseline.
  • Which OS variant to use? For historic, work and family reasons my PCs all currently run WinXP. However, the only way you can develop and debug on WinXP in a supported way is by paying for Microsoft development tools and I was reluctant to do this, so a Linux build was the obvious choice. Since I had set up a PC with an openSUSE 10.1 and liked the overall integration, ans found it a nice bundle with a lot of Windows features, my first start was based on this. However, I found it too like Windows, and I like my development environments 'lean and mean', so I ended going back to Ubuntu. I just felt more comfortable there, OK.
  • Dedicated or VM? I am pre-fashionable Green. I hate having too many boxes, big electricity bills and a noisy office. I also hate chucking stuff away. I also like sandpits that I can take anywhere and the means Virtual. Clearly another advantage of this is that you can decouple your sandbox OS from your host OS, especially if your VM monitor supports mulit-platform hosting (thus eliminating MSVPC and Xen, etc. from my options). This drew me to the free, though not FLOSS, VMware Player product as my runtime vehicle of choice.
  • One 'disk' or two? Again after various debates and getting burnt, I decided to split my VM over two virtual HDDs. Splitting it into separate system disk + dev disk makes a lot of sense. The system disk is pretty non-volatile as far as development goes so the image can be backed up once and replicated across shared developers easily, since the ZIP container is less than 1Gbyte. The dev disk basically contains the OOF680xxx dev tree. This is also a lot easier to back up, say by ZIPing it into a backup directory. This ZIP will fit onto a DVD or a large USB stick, just in case you want to collaborate or move the dev environment around.

You need at least 1Gyte RAM in your PC with 2 Gbyte preferred (or required if you use Vista as your OS). You will need also quite a lot of room on a HDD that you are going to use. I would recommend a minimum of 20Gbyte. You are going to run your development environment in a VM which needs to be hosted on your native OS, so keep away from Xen if you use Linux -- at least for this approach. As I said, it doesn't matter whether your host is WinXP (etc.) or Linux, but if you follow this page you are going to be doing all your hacking in a guest VM which runs Ubuntu 6.10 variant of Linux, so you will need some familiarity with the GNU/Linux development tools.

Setting up for the Build

Setting up the System

First you need to download the VMare Appliance Player from VMware Player Download. You will need the correct kit according to whether your machine runs Window or Linux. Install this on your PC, and create a container folder on your HDD to hold your work. You next need to download the Ubuntu 6.10 Appliance VMware Virtual Applicance MarketPlace, and the one that you are looking for is the "Ubuntu 6.10 (Edgy)" appliance. This is an HTTP download of a ZIP file of around 755MBytes, so broadband is essential. Create a directory called Ubuntu 6.10 on your host PC and extract the VMDK file in the downloaded zip file into this folder, then rename it to Ubuntu1.vmdk. (You'll see why later). Now download [this ZIP file] which contains the rest of the files that you need to build your appliance and add them to your Ubuntu 6.10 folder, so that it shoul now contain the following files:

  • ubuntu.vmx. This contains the parameter which the VMserver what devices are attached, such as Virtual HDDs, CDs, scree etc.. Note that this is configured to support two VMDKs.
  • ubuntu1.vmdk. This is the downloaded virtual disk contain /root /home etc. It's only and 8Gbyte image which is just too small to build OOo 2.2.1 for hacking, so I have added
  • ubuntu2.vmdk. This contains an empty 12Gbyte efs3 partition, which shows up in the system as /dev/sdb2, and it is in this that you will build the OOo kits.
  • ubuntu.mvram. This contains the virtual BIOS.
  • ubuntu.vmsd. This is the snapshot file. See VMware Files Explained for more details.

There is some customisation that you need to do when you start up the image for the first time:

  • Hit ESC when you first enter the grub loader and select the recovery mode. This brings you into the console prompt. Change directory to /etc/X11 and remove the copy back the xorg.conf. backupBeforeVMtoolsInstalled back over xorg.conf, then hit ^D to continue the boot. (The reason for this was that the creator of the kit did a sudo dpkg-reconfigure -phigh xserver-xorg which replaced the standard VMware xorg.conf, and without this you can't get sensible screen sizes in your VM.
  • You also need to go into System->Preferences and System->Administration to configure your keyboard, mouse, Time region, etc.. For some reason, I've found that the network needs one reboot before the device drivers see it. You may find it useful at this stage to enable samba file sharing and Remote desktop takeover. If you do set up samba then don't forget to do the sudo smbpasswd commands to register and enable your account.
  • You also need to think about the security of your VM because when running it is another machine on the network, and just as vulnerable to attack. If you are doing this in a shared work environment, you might want to consider whether you want to move your VM from a bridged NAT based Ethernet emulation. You should also change the default ubuntu password and default root passwords, and other lockdown parameters.

Since the Ubuntu kit by design a fairly minimalist install, some of the packages that you need are missing from the base VM build, so you will also need to do a 

sudo apt-get -y install cvs automake1.9 build-essential libpam0g-dev libpng12-dev flex \
    bison libgtk2.0-dev 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 libnspr-dev libnss-dev libsane-dev libxaw-headers \
    libbonobo2-dev libaudio-dev libsndfile1-dev libgnomevfs2-dev \
    libstartup-notification0-dev ant

Also a few of the packages expect headers in the wrong directories, so you also need to add the following symlinks to make the compile work: 

cd /usr/include
sudo ln -s /usr/lib/jvm/java-gcj/include/jni.h
sudo ln -s /usr/lib/jvm/java-gcj/include/jni_md.h
sudo ln -s /usr/lib/jvm/java-gcj/include/jawt.h
sudo ln -s /usr/lib/jvm/java-gcj/include/linux/jawt_md.h
cd /usr/lib
sudo ln -s libXaw7.so.7.0.0 libXaw.so

You now need to setup your dev-disk, so the first thing that you need to do is to create amount point and mount it. This is basically an empty efs3 12Gyte disk with one file in a folder called misc: the config.sh which contains the configure command discussed later. 

cd ~
sudo mkdir /OOO-dev
mount /dev/sdb1 /OOO-dev
ls -l /dev/disk/by-uuid
ln -s /OOO-dev/misc misc
sudo mkdir /OOO-dev/OOF680_m18
sudo chown ubuntu:ubuntu /OOO-dev/OOF680_m18 
ls -s /OOO-dev/OOF680_m18

Clearly for the later builds you will need a different OOF680xxx directory. You may also at this stage add the sdb1 mount to your fstab; one of the above commands lists off the uuid that you need.

You also need to remove the use System->Synaptic Package Manage to remove the pre-installed OpenOffice configuration. Look for OpenOffice.org-core, remove this and the manager will unistall the rest.

Setting up the Dev Environment

Now download the source tarballs from OpenOffice.org 2.2.1 Source into a temporary directory and unpack into ~/OOF680_m18 directory. You will also need to download the Mozilla libraries and store them in ~/OOF680_m18/moz/zipped. Now do the build. 

cd /OOO-dev/OOF680_m18
cd configure_office
source ~/misc/config.sh
./bootstrap
cd ..
source LinuxIntelEnv.Set.sh
dmake >& ~/logs/dmake1A.log

The configure command contains a help overview which you can see either by viewing the configure.sh command in the configure_office module or by executing it with the --help parameter. The one that I've provided contains the following parameters. How I arrived at these was a bit of black art, I'm afraid; somewhat informed by the ooo-build parameter set. My main aim here was to get a buildable system for test rather than one which gives absolutely the best user experience whilst using OOo itself. This set enables a full compile to complete and soffice works fine. So if I were you, I'd start with this and tweak it to your specific needs. 

--disable-binfilter --disable-cairo --disable-crashdump --disable-fontooo \
--disable-gstreamer --disable-gtk --disable-kde --disable-build-mozilla \
--disable-odk --disable-qadevooo --disable-mathmldtd \
--enable-atkbridge --enable-crypt-link --enable-libsn --enable-pam-link \
--enable-pasf --enable-symbols --enable-xsltproc \
--with-alloc=system --with-distro=Ubuntu --with-jdk-home=/usr/lib/jvm/java-gcj \
--with-lang=en-US --with-openldap --with-system-curl --with-system-expat \
--with-system-freetype --with-system-gcc --with-system-jpeg --with-system-libxml \
--with-system-nas --with-system-odbc-headers --with-system-python \
--with-system-sane-header --with-system-sndfile --with-system-stdlibs \
--with-system-xrender-headers --with-system-zlib --with-use-shell=bash \
--without-agg --without-fonts --without-gpc --without-myspell-dicts \
--with-build-version=Terry OOo 2.2.1  
CC=gcc

The machine is going to be pretty much 100% compute bound for the next 12 hrs, or thereabouts depending largely on the CPU speed. Note that I decided not to use the solver tarball, as I find the full compile more flexible. Go to bed / wait until this completes. Lastly, you need to install it into /opt/openoffice.org2.2 ready for hacking, and since you want to do all your hacking in user ubuntu change the ownership to this account. Having done this you should now be able to avoid use of sudo in your normal development. 

cd ~/OOF680_m18/instsetoo_native/unxlngi6.pro/OpenOffice/deb/install/en-US
sudo dpkg --install -R DEBS
cd /opt
sudo chown -R ubuntu:ubuntu openoffice.org2.2

Moving on to Debugging

This default config.sh used above enables symbols which does all compiles and links with the -g option, which is why a 12Gbyte dev partition is needed. However, you will find that whilst the binaries and shared libraries moved to the solver directory have their symbols included, the ones in the DEB kits and therefore installed into /opt have the symbols stripped to speed loading. This also has a major advantage that when you start debugging the size of the gdb process is significantly smaller than with all symbols load because the symbol tables for the full soffice.bin plus shared libraries is HUGE.

So let's assume that you have decided to focus on one module — basic say — and you want to start hacking in this. The first thing that you will need to do is to go into the source tree and start to make your changes. Let's take an example: you want to turn on the diagnostic feature of emitting Basic assembler listing. This one is easy all you need to do is to uncomment one line in basic/source/comp/sbcomp.cxx which is to remove the comments on the following line to define the symbol DBG_SAVE_DISASSEMBLY. 

//#define DBG_SAVE_DISASSEMBLY

You can now save the file and do a build followed by a deliver in the module's root directory ~/OOF680_m18/basic. You will see that this moves some files into the solver tree. The key one here is the shared library libsb680li.so that contains all the executable code for the basic module. You now need to rehook the symlink /opt/openoffice.org2.2/program/libsb680li.so which currently refers to the symbol stripped shared library in the same directory: 

cd /opt/openoffice.org2.2/program
ls -l libsb*
rm libsb680li.so
ln -s /home/ubuntu/OOF680_m18/basic/unxlngi6.pro/lib/libsb680li.so

Now if you start to debug soffice as follows: 

cd /opt/openoffice.org2.2/program
gdb soffice.bin
r -calc

You are away and debugging. By the way when you do try to run this you will find that you will get a memory exception because of a bug in the Novell VBA code changes in open of the npower changes. Hint: have a look at the ex/i for the line that crashes. You will see that the stack frame is >2Gb. Oops. Someone has got there sizing wrong.

Still you are now debugging soffice!

See Also

Retrieved from "https://wiki.openoffice.org/w/index.php?title=Ubuntu_Build_in_a_VMware_Appliance&oldid=43489"
Personal tools