As most of you already know I’m not exactly a GNOME fanatic, rather, I at least used to be a KDE developer (only extragear, and lately I haven’t had time to work on anything KDE-related). Unfortunately as now I’m the Deputy Lead of Gentoo/BSD project (thanks Stephen, Seemant and Grant for this opportunity), I can’t just say “GNOME is not my stuff” and I started looking to have it working on Gentoo/FreeBSD.
The first problem was with glib itself, as there were problems with threading, so I took some patches from FreeBSD’s ports and now should be working fine, at least on my system, until this is committed on official portage tree.
What stopped me quite immediatly was a problem with docbook-related stuff, that today – thanks to Riccardo “mala” from VElug who helped me tracking down files on his Gentoo system that had already GNOME installed – turned out to be an error in the sgml-catalog eclass (it use seq command, that’s not available on BSD userlands, while is available on GNU and Darwin userlands). Unfortunately the error was quite criptic, and I had problems trying to check it on my machine as opensp emerge process ICEd out (systematically, so it’s not a problem with my machine, but probably with the code and GCC4).
Now that is solved on my local tree and I filed bugs for the SGML-related ebuilds to fix this problem and an ebuild that was using cp -a (thus breaking on BSD userland).
Then the turn was of the most stupid bug I could find, but a quite annoying one, with scrollkeeper. But we need a bit of history for this.
The nls useflag is usually expanded in –enable or –disable-nls parameter to configure, that are managed by gettext M4 library to enable or disable i18n support in applications. GNU libc (glibc) provides gettext functions inside libc, while on BSD and Darwin you must use libintl to have them, linking to it explicitely; Gettext takes care of defining LTLIBINTL variable when –enable-nls (the default) is passed. Software should then disable NLS support checking for ENABLENLS preprocessor macro on config.h file generated by configure, but ….
But on Linux systems you usually use glibc, so you don’t see errors while using the gettext functions with –disable-nls, as they are in the libc as we said; instead on a FreeBSD system, the package fails to link because of unsatisfied references to libintl* functions.
This was what happened to scrollkeeper. What really surprised me is that scrollkeeper is not exactly a mostly-unused program, it’s present on FreeBSD ports (who just forced –enable-nls) and it’s released quite often. There was bug #4071 that reported problems while building with -nls, but that was worked around with touch of a false empty header. Also if -nls was asked, scrollkeeper always built with nls support.
I’ve patched scrollkeeper and posted the patch upstream, I’ve opened a but to get it in portage (as it’s required for Gentoo/FreeBSD to work well). When that will be done, if you want to get rid of nls on scrollkeeper, rebuild it, and it will be ok. While this seems to be a minimal overload as glibc still get linked, there’s a little slowdown when starting an NLS-enabled program, as it has to load the locale data.. and scrollkeeper is run by many GNOME-related ebuilds… so maybe this can affect slighly users…
For who wants to see when GNOME will work out of the box on Gentoo/FreeBSD, there’s a tracker bug #103124, where I’m adding all the bugs that breaks GNOME on Gentoo/FreeBSD. The key of this process is “push upstream” as usual, I also registered to GNOME Bugzilla to submit patches when needed, as was for ORBit (that’s now fixed upstream).
On a side note: I always hear people saying that KDE takes an hell of time to build completely and so on… while it’s true that qt and kdelibs takes a lot of time to build, I’d like to say a couple of things about this on my first gnome emerge that’s running on Gentoo/FreeBSD.
First of all, KDE library deps are a bit less invasive… I got pango or some other library changing its soversion lately on the G/FBSD box and I had to rebuild the entire XFCE4 (that was already installed), while only minimal breakage came up on the Linux box with KDE. That’s not good.
Second, while QT and kdelibs are slow to compile, “emerge gnome” requires me to build Mozilla… and this has a big disadvantage: you need to rebuild it every time a security problem is found, and this is not exactly a “2 minutes” compile…
