The other side of the moon

...or how to end up with bloodshot eyes

Let me get this out right at the start. Current versions of Gnome (2.18) can be made to build on FreeBSD 4.x, but the default ports configs won't. You'll have to do a lot to get it working, and sometimes, just give up and skip a package.

I'm not going to list everything mainly because I didn't keep notes and I don't remember everything that I did. I'll list here the most memorable issues and what I did to fix them.

1. x11/gnome-applets

The gnome2 meta package depends on a whole load of other packages, and gnome-applets is the first of theses. It pulls in several applets, and tries to link itself against hal and gstreamer-plugins. Problems all along.

For starters, one of the packages it tries to pull in is gtop (from devel/libgtop). So? So this is something that reads the kernel's process table, and to do that, it uses struct kinfo_proc from /usr/include/sys/user.h. Not such a big deal until you realise that this struct has changed completely from FreeBSD 4.x to FreeBSD 5 and 6. So, I started to fix the code by looking up proc.h and user.h for equivalent struct members. This process was slow and painful, and I couldn't guarantee correctness.

Then I thought to myself and realised that I've never in my life run gtop. I always opena shell and run top. Discard package.

So I opened x11/gnome-applets/Makefile, and removed the line that said:
gtop-2.0.7:${PORTSDIR}/devel/libgtop \

First problem solved.

Second problem was building against hal (sysutils/hal), which has this little snippet in its Makefile:

.if ${OSVERSION} < 505000
IGNORE=  not supported on FreeBSD prior to 5.5-RELEASE
.endif

Which basically says that hal won't build on FreeBSD less than 5.5. This was easily solved though, just append --without-hal to CONFIGURE_ARGS and you're done. The third issue - multimedia/gstreamer-plugins had a similar issue:

.if ${OSVERSION} < 500000
IGNORE=        many plugins don't build or even work on 4.x
.endif

I was feeling a little ambitious here, so I said, let's see what doesn't build, and I commented out those lines from multimedia/gstreamer-plugins/Makefile, and then started to build the plugins. Guess what? All of them built. Got back to gnome-applets, and hit another snag. This time it was gnome-control-center, which needed libgnomekbd, which depends on libxklavier. Nothing particularly wrong with this, except that libxklavier has include files installed in two locations, and one of them is wrong. Basically, you have /usr/local/include/libxklavier (correct) and /usr/X11R6/include/libxklavier (wrong). My guess is that the incorrect one came from an older install. Problem is that X11R6 shows up earlier than local in the include path, and so libgnomekbd tries to use those headers rather than the ones in local. Compile fails. Looked up on the net, and again found a solution that said "rm -rf /usr/X11R6/include/libxklavier". I tried the more circumspect "mv libxklavier old-libxklavier" instead. Retried, and libgnomekbd built. Returned to gnome-applets and everything started building, except...

2. documentation and help files weren't getting generated

I was getting errors with xmlPathToURI:

Traceback (most recent call last):
File "/usr/local/bin/xml2po", line 34, in ?
import libxml2
File "/usr/local/lib/python2.4/site-packages/libxml2.py", line 1, in ?
import libxml2mod
ImportError: /usr/local/lib/python2.4/site-packages/libxml2mod.so:  
Undefined symbol "xmlPathToURI"

A web search told me that I should rebuild textproc/py-libxml2, so I did that. It went smoothly, and fixed the problem, but another problem showed itself. I started getting a Bus Error on calls to xsltproc - also used for generating gnome docs. Did a pkgdb lookup on /usr/local/bin/xsltproc, which told me that it came from libxslt. I proceeded to rebuild that, and once done, docs and help files started getting generated.

3. devel/gnome-vfs

I also needed to build things like abiword, gnumeric, gnome-terminal, eog and gthumb, and all of these require gnome-vfs, which also depends on hal. This was another quick fix.I commented out these line:

LIB_DEPENDS=   hal.1:${PORTSDIR}/sysutils/hal

...

--enable-hal \
--with-hal-mount=/sbin/mount \
--with-hal-umount=/sbin/umount

and rebuilt gnome-vfs. All okay, except bookmarks won't automatically be monitored. Can't say that I care.

4. Photos

Now remember, one of the things I needed was gthumb, and I wanted it to be able to read directly from my camera using libgphoto2... unfortunately, libgphoto2 requires libgphoto2_port which requires libusb, which, for some reason, didn't build from ports the last time I'd tried. IAC, I'd installed all three from source, and they worked perfectly for command line access to my camera. Problem is that the source install of libgphoto2 put its pkg-config file into /usr/local/lib/pkgconfig, while FreeBSD's pkg-config reads from /usr/local/libdata/pkgconfig, and because of this, gthumb kept assuming that libgphoto2 couldn't read from a camera. I added the directory to PKG_CONFIG_PATH and reconfigured, and it built correctly.

6. nautilus

Now this is something I couldn't understand, but I managed to fix anyway. A few things stopped me while building nautilus. First, I got stuck building nautilus-shell-interface.idl on typedef sequence<URI> URIList; because it couldn't find a definition for the type called URI. All the correct files were included, so not sure what the problem was. I noticed that URI was a typedef of string, so just changed the line to typedef sequence<string> URIList; and it worked. The next thing that came up was a little more complicated. Basically, src/nautilus-application.c has a call to CORBA_sequence_Nautilus_URI_allocbuf, but this function isn't defined anywhere, and apparently, I'm not the only person who has this problem. I took a hint from the guy at that URL, and decided to allocate the memory myself, but I had to make a few guesses on what it did. Read through the code, and realised that uri_list->_buffer was an array of URIs, and URIs were basically strings, so I changed the code from this:

uri_list->_buffer = calloc(length, sizeof(CORBA_string));

to this:

uri_list->_buffer = CORBA_sequence_Nautilus_URI_allocbuf(length);

The code compiled, and linked successfully, and I haven't had any lockups at all.

Finishing up

At the end of it all, I discovered that ayttm wouldn't start because it couldn't find libgmodule.so. Tried rebuilding, but it couldn't link, so I ended up installing the new gtk+20 package, and then ayttm built, but... Now gnome-terminal started freezing up. Rebuilt gnome-terminal against the new gtk+ and everything has been smooth since... except for the missing icon in the top left corner of my screen and the gnome dictionary applet, which won't start. Will investigate further. Update: 2007/04/23 I've had a few more problems since last night. Minor ones. Basically, while building gdm, the xml parser was barfing on — and %:

uk/gdm.xml:2358: parser error : Entity 'mdash' not defined
<para>%r &mdash; випÑÑк (веÑÑÑÑ OS)
^
uk/gdm.xml:2360: parser error : Entity 'percnt' not defined
<para>%s &mdash; назва ÑиÑÑеми (ÑобÑо ÐиÑÑеми (ÑобÑо Ð

Again, a web search found others who've had this problem, but there wasn't a solution, just a note that it doesn't break anything. I decided to fix it with this little script:

cd work/gdm-2.18.1/docs
perl -pi -e 's/—/\—/g' `grep -rl '—' *`
perl -pi -e 's/%/\%/g' `grep -rl '%' *`

and all's well. Update: 2007/05/10 One of the packages I hadn't upgraded the last time around was deskutils/gnome-utils. This contains a bunch of useful applets like GDict, which I use a lot. I started building it, and ran into the old libgtop problem. This time, just commenting out the entry from the makefile didn't help. The configure script cried out as well. So, I did this:

cd work/gnome-utils-2.18.1
vi gnome-utils-2.18.1

Search for LIBGTOP_REQUIRED, and changed the version from 2.12.1 to 2.10.0 (the version I have installed). No more complaints about libgtop, but... While building, the compile stopped somewhere inside baobab because one of the files included monetary.h. This header does declares strfmon, and little else. It also doesn't exist.

I checked the code, verified that there were no calls to strfmon, and removed the reference to this header. The compile proceeded smoothly, and I now have gnome-utils installed.