I've been wandering aimlessly trying to come up with a project to hack on and keep running into brick walls or out of motivation. Having exhausted my ideas I figure I may as well spend some time trying to fix some gnome-love bugs and see where that leads me.

My weekend project has been compiling Gnome 2.18 from source, a notoriously brutal exercise and my experience would be no different. To make matters worse I'm using the amd64 port of Debian Etch, and this causes no shortage of complications. I actually started working on this late last week and have been tinkering with it (here and there) for almost 5 days. Perseverance is key, I do want to get setup to start hacking on Gnome, plus Etch only has Debian 2.14 so it'll be nice to spend my days in the latest Gnome code. 2.18's release is just around the corner.

The process goes something like this, install jhbuild, setup a ~/.jhbuildrc, jhbuild bootstrap, jhbuild build. You can find some information on the subject at this location, just remember to adjust accordingly for the fact that Gnome has switched to subversion (instead of cvs). The steps seem relatively straightforward and considering what's actually going on, jhbuild does a remarkable job, but the process is still littered with compilation failures (many dependences need to be installed), incorrect paths (especially with amd64), mysterious unresolved symbols and references that appear and disappear on recompiles, etc. I kept notes on everything I went through during the process in the hopes that it'll help others out there attempting to do the same.

Before You Start

apt-get install

Firstly a list of packages I had to install as dependencies. apt-getting these beforehand will save you lots of interruptions in your compile.


apt-get install libxml-perl docbook-xsl ccache flex bison libpopt-dev libfreetype6-dev libpng3 libxft-dev libtiff4-dev libxt-dev lynx libgdbm-dev libbz2-dev libxml-simple-perl libxml2-dev python-libxml2 cvs libcupsys2-dev libexif-dev libgstreamer0.10-dev wireless-tools libxtst-dev libiw-dev libnl-dev libexchange-storage1.2-dev libldap2-dev libxmu-dev xnest libgpgme11-dev


PKG_CONFIG_PATH

There seems to be lots of pkg-config problems, dependency packages end up in /usr/lib/pkgconfig/, but the gnome build looks for the .pc files in /opt/gnome2/lib/pkgconfig (or /opt/gnome2/lib64/pkgconfig/, or both, as the case may be) Save yourself a lot of trouble and export this PKG_CONFIGPATH before you start.


export PKG_CONFIG_PATH=/opt/gnome2/lib64/pkgconfig:/opt/gnome2/lib/pkgconfig:/usr/lib/pkgconfig


libexchange

evolution-data-server doesn't build libexchange by default because it doesn't link with openldap by default. (see this link) Add the following to your ~/.jhbuildrc to ensure that it does:


module_autogenargs['evolution-data-server'] = autogenargs + ' --with-openldap'


Problems and Solutions

Now for the not-so-plesant compile errors that required some kind of manual hackery:

Python Unicode


ImportError: /opt/gnome2/lib/python2.4/lib-dynload/cPickle.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
*** error during stage build of dbus-python: ########## Error running python setup.py build *** [25/147]


This was a weird one, but I eventually concluded that the version of Python jhbuild compiled during the bootstrap phase didn't have unicode support. I don't know why jhbuild feels it's best to recompile Python when I already have it on my system, probably just to make sure everything plays nice together. I also don't know why unicode support wasn't included, ./configure --help lists YES as the default for --enable-unicode. Regardless while sitting at the jhbuild prompt for this error, I cd'd into the source dir where jhbuild compiled python from and did:


./configure --enable-unicode --prefix=/opt/gnome2/
make
make install


Python libxml2

Despite having python-libxml2 installed, I got failures complaining that it couldn't be imported when building gnome-desktop. Again, rather than adjust the PYTHONPATH properly I just did a dpkg -L python-libxml2 to see what it installed and copied the appropriate files to /opt/gnome2/lib/python2.4/.


cp /usr/lib/python-support/python-libxml2/python2.3/libxml2mod.so /opt/gnome2/lib/python2.4
cp /usr/share/python-support/python-libxml2/libxml2.py /usr/share/python-support/python-libxml2/drv_libxml2.py /opt/gnome2/lib/python2.4


Pangox.h

Another problem mid-way through the Mozilla compile complaining about missing pangox.h.


cp /usr/include/pango-1.0/pango/pangox.h /opt/gnome2/include/pango-1.0/pango/


R_X86_64_PC32

If you're compiling on amd64 you may run into a problem during the Mozilla compile like this:


/usr/bin/ld: ../../dist/lib/libxpcom_core.a(nsCOMPtr.o): relocation R_X86_64_PC32 against `nsGetServiceByContractIDWithError::operator()(nsID const&, void**) const' can not be used when making a shared object; recompile with -fPIC


See this post for more information, but the fix basically amounted to me creating ~/.mozconfig with this line:


ac_cv_visibility_pragma=no


After which I had to make sure to 'make clean' in the mozilla directory and then rerun the configure stage.

Assorted Other Issues

I frequently ran into issues with unresolved references that just required jigging around. Normally I'd try to figure out what module hosts the missing method, go back to it manually and ./configure with appropriate options, make clean and recompile it, then clean the module that failed and try that again. More often than not this works for most unresolved references.

Links

• gnome-love compiling FAQ