Hadn’t compiled GNOME for a while so I gave it a shot yesterday evening. I ran jhbuild build evolution which should build everything required for Evolution. I had a fresh and empty install directory.
I don’t post this to blame anybody but I wonder how many people give up at this stage and how many potential non-1337h4x0r5 contributors GNOME loses because of such build problems. Teh fun.
gtk+-3 and gtk+:
Problem: This atk bug.
Workaround: Edit /home/user/installdir/share/gir-1.0/Atk-1.0.gir by changing the line <repository version=”1.0″ to <repository version=”1.2″.
gnutls-2.8.6:
Problem:
make[4]: Entering directory `/home/user/checkoutdir/gnutls-2.8.6/doc/examples’
[…]
/usr/bin/ld: ex-serv1.o: undefined reference to symbol ‘gcry_control@@GCRYPT_1.2’
/usr/bin/ld: note: ‘gcry_control@@GCRYPT_1.2’ is defined in DSO /home/user/installdir//lib/libgcrypt.so.11 so try adding it to the linker command line
/home/user/installdir//lib/libgcrypt.so.11: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[4]: *** [ex-serv1] Error 1
[…]
/usr/bin/ld: ex-serv1.o: undefined reference to symbol ‘gcry_control@@GCRYPT_1.2’
/usr/bin/ld: note: ‘gcry_control@@GCRYPT_1.2’ is defined in DSO /home/user/installdir//lib/libgcrypt.so.11 so try adding it to the linker command line
/home/user/installdir//lib/libgcrypt.so.11: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[4]: *** [ex-serv1] Error 1
Workaround: Edit doc/examples/Makefile.am and change AM_LDFLAGS = -no-install to AM_LDFLAGS = -no-install -lgcrypt. See this bug report.
nss-3.12.6
Problem:
drbg.c: In function ‘RNG_RandomUpdate’:
drbg.c:510: error: size of array ‘arg’ is negative
drbg.c:513: warning: large integer implicitly truncated to unsigned type
make[4]: *** [Linux2.6_x86_glibc_PTH_OPT.OBJ/Linux_SINGLE_SHLIB/drbg.o] Error 1
make[4]: Leaving directory `/home/user/checkoutdir/nss-3.12.6/mozilla/security/nss/lib/freebl’
make[3]: *** [libs] Error 2
drbg.c:510: error: size of array ‘arg’ is negative
drbg.c:513: warning: large integer implicitly truncated to unsigned type
make[4]: *** [Linux2.6_x86_glibc_PTH_OPT.OBJ/Linux_SINGLE_SHLIB/drbg.o] Error 1
make[4]: Leaving directory `/home/user/checkoutdir/nss-3.12.6/mozilla/security/nss/lib/freebl’
make[3]: *** [libs] Error 2
Workaround: Could not find any, hence ugly: Commented line 510.
Next problem: Now the next modules will fail with
/usr/bin/perl: /home/user/installdir/lib/libfreebl3.so: version `NSSRAWHASH_3.12.3′ not found (required by /lib/libcrypt.so.1)
Workaround: Tried adding #module_makeargs[‘nss’] = makeargs + ‘CFLAGS+=”-FREEBL_NO_DEPEND=1″‘ to ~/.jhbuildrc but that did not help. Just deleting the offending file /home/user/installdir/lib/libfreebl3.so worked though (probably uses the system one in that case). Hmm.
NetworkManager (branch NETWORKMANAGER_0_7)
Problem:
configure.ac:64: warning: AM_NLS is m4_require’d but not m4_defun’d
Workaround: See this thread.
Next problem:
checking for POLKIT… configure: error: Package requirements (polkit-dbus) were not met:
No package ‘polkit-dbus’ found
No package ‘polkit-dbus’ found
Workaround: jhbuild build PolicyKit (which will create the missing file /home/user/installdir/lib/pkgconfig/polkit-dbus.pc)
sqlite3-3.6.23.1
Problem:
tclsh ./tool/mksqlite3h.tcl . >sqlite3.h
/bin/sh: tclsh: Command not found
make: *** [sqlite3.h] Error 127
/bin/sh: tclsh: Command not found
make: *** [sqlite3.h] Error 127
Workaround: Using module_autogenargs[‘sqlite3’] = autogenargs + ‘ –disable-tcl’ in ~/.jhbuildrc did not work anymore, hence after reading the upstream bug report I grumpily installed TCL from the system repository.
gtkhtml
Problem:
In file included from html.c:32:
../gtkhtml/htmlengine.h:63: error: expected specifier-qualifier-list before ‘GdkGC’
html.c: In function ‘html_a11y_get_extents’:
html.c:321: error: ‘HTMLEngine’ has no member named ‘x_offset’
html.c:322: error: ‘HTMLEngine’ has no member named ‘y_offset’
make[2]: *** [html.lo] Error 1
make[2]: Leaving directory `/home/user/checkoutdir/gtkhtml/a11y’
../gtkhtml/htmlengine.h:63: error: expected specifier-qualifier-list before ‘GdkGC’
html.c: In function ‘html_a11y_get_extents’:
html.c:321: error: ‘HTMLEngine’ has no member named ‘x_offset’
html.c:322: error: ‘HTMLEngine’ has no member named ‘y_offset’
make[2]: *** [html.lo] Error 1
make[2]: Leaving directory `/home/user/checkoutdir/gtkhtml/a11y’
Reason: GdkGC does not exist in GTK3 anymore, hence rendering needs porting to Cairo. Filed bug 630072 and gave up on this module.
avahi-0.6.27
Problem:
GISCAN Avahi-0.6.gir
g-ir-scanner: warning: Option –strip-prefix has been deprecated;
see –identifier-prefix and –symbol-prefix.
AvahiCore-0.6.gir: Incompatible version 1.0 (supported: 1.2)
make[3]: *** [Avahi-0.6.gir] Error 1
make[3]: Leaving directory `/home/user/checkoutdir/avahi-0.6.27/avahi-gobject’
g-ir-scanner: warning: Option –strip-prefix has been deprecated;
see –identifier-prefix and –symbol-prefix.
AvahiCore-0.6.gir: Incompatible version 1.0 (supported: 1.2)
make[3]: *** [Avahi-0.6.gir] Error 1
make[3]: Leaving directory `/home/user/checkoutdir/avahi-0.6.27/avahi-gobject’
Reason: Old .gir format. I edited avahi-gobject/AvahiCore-0.6.gir and replaced <repository version=”1.0″ by <repository version=”1.2″, and in configure.ac I replaced GOBJECT_INTROSPECTION_CHECK([0.6.7]) by GOBJECT_INTROSPECTION_CHECK([0.9.5]).
But that did not help – next problem:
But that did not help – next problem:
GISCAN Avahi-0.6.gir
[…]
AssertionError: Failed to parse toplevel type
[…]
AssertionError: Failed to parse toplevel type
After finding the corresponding bug report I gave up on this module.
After all I couldn’t build evolution of course (No package ‘libgtkhtml-4.0’ found).
Not very productive, and right now I’m too annoyed to edit the JhbuildIssues wikipage.
Years ago during grad school I had decided that I would like to become a GNOME contributor. I picked a few bugs from bugzilla and started working on them, but I spent all of my time trying to maintain a working build environment. I eventually gave up and took up jogging instead.
@Tom: running is good for your health. more hackers should actually pick it up. if you want to contribute to GNOME, though, having a build environment is unfortunately necessary — and if you’re not going for the ultra-bleeding edge like Andre is doing, then it’s pretty easy to pick it up with jhbuild. if something breaks, then feel free to do what Andre does, and file bugs.
Ahah, there’s a trick you should learn: you don’t need to build gnutls, nss, NetworkManager, sqlite, or avahi! Just use the devel packages from your distribution. It makes like so much easier ;-)
I have this in my ~/.jhbuildrc:
skip = [ ]
# skip from bootstrap
skip.extend ([ ‘python’, ‘guile’ ])
# skip some big external dependencies that can be annoying and that are
# installed system-wide anyway
skip.extend ([ ‘mozilla’, ‘firefox’, ‘dbus’, ‘hal’, ‘avahi’, ‘NetworkManager’, ‘PolicyKit’, ‘PolicyKit-gnome’, ‘libgdiplus’, ‘mono’, ‘monodoc’, ‘nss’, ‘nspr’, ‘sqlite3’, ‘pulseaudio’, ‘pysqlite2’, ‘mono-addins’, ‘WebKit’, ‘polkit’, ‘DeviceKit’, ‘DeviceKit-disks’, ‘DeviceKit-power’, ‘libxml2’, ‘libxslt’, ‘libgpg-error’, ‘libgcrypt’, ‘expat’, ‘libtasn1’, ‘gnutls’, ‘libvolume_id’, ‘libdaemon’, ‘udisks’, ‘UPower’, ‘upower’ ])
@Vincent Untz: Thanks! I’m aware of it, but it might be a very good recommendation to new contributors.
I’ve nver been a fan of jhbuild because its default setup sucks. It tries to compile all this crap from the newest devel packages that is working fine on my system and not needed for the package I want to compile.
I’ve always attributed my unhappiness with jhbuild to me being smart enough to build stuff myself. But considering that all the heavy builders (see Vincent above) use it themselves, I’m starting to suspect that jhbuild needs someone to redesign its internals with a focus on getting specific packages built with as little work as possible instead of trying to build the whole thing. jhbuilding shouldn’t be like building linuxfromscratch.
Jhbuild is only half the problem here, though – the bigger problem is that the Gnome tree is in a rather unstable state at the moment, no matter what tool you use to build it. I’ve been tracking 2.32, and it’s been pretty bad as well – mostly from the gobject-introspection incompatibilities you noted, and also from general confusion from the introduction of 2.32 between 2.30 and 3.0. Looking better now, but it’s really concerning just how much change is still happening a couple of weeks from release.
As for tracking 3.0, I gave up on that when the big GDK cleanup went in. There were so many failing packages after that that it just wasn’t worth wasting any more time on it.
Some years ago, I had decided to contribute to Gnome. After lot of hours spend to try to compile with jhbuild, and make some contributions to the wiki to help other peoples for that, I gave up. A unusable build system it definitively not serious. I don’t understand how gnome is released.
So, sometime, I just contribute with translations.
@Vincent Untz : Interesting, but if there is not explanation on the gnome-love wiki or docs, it’s like that’s doesn’t exist.
W.R.T. Evolution (and GtkHtml), it was when GdkGC was dropped that Chenthill and I agreed GTK3 was still too much of a moving target to bother with until after 2.32. Bad idea to for us to go screwing around with ancient but critical GDK code so code to a stable release. We’ll spend the 2.33 cycle chasing GTK3 again as best we can.
I wrote about similar problems on gnome desktop mailing list some time ago. I don’t want necessary the most unstable builds but the GdkGC on Gtk caused serious problems – some packages required version = 2.90.6. I don’t use jhbuild however as I don’t feel that /home is the best place for GNOME installation (I tried to system install it). Second problem is gobject-introspection…
I am being afraid that GNOME 3 somehow does not follow release early, release often principle and it will run into problems with untested code – especially when it is not possible to get a build with every package more-or-less stable instead of hand-patching git repositories.
I am being afraid that GNOME 3 somehow does not follow release early, release often principle and it will run into problems with untested code.
I think at this point, the problem is almost the opposite of that – releases are coming plenty often enough, but are providing a constantly moving target for consumers. Particularly for gobject-introspection – all the packages that failed when the file version changed from 1.0 to 1.1 had only just updated to 1.1 when GI 0.9.5 moved to a 1.2 format. I’ve seen the same feelings expressed with regard to the GApplication mess – unhappy developers that have been quick to buy into the idea are feeling burned now that the API is being dropped.
Well. It depends on which POV you are looking. I meant lack of often, working releases of whole desktop env as oppose to often releases of various things that may or may not work. In addition to long development “runs” without releases (like gnome-shell – they seems to have 2 moths of heavy coding without release – at least they talked about a lot of features on GUADEC that are not present in 2.31.5).
IMHO main problem with GI 0.9.5 is that it changed parameters and haven’t left the old ones for backward compability. Otherwise I’d just rebuild the packages that installs those files (I use Gentoo). Change 0.6.x -> 0.9.3 was simpler then 0.9.3 -> 0.9.5.
@Emmanuele Bassi: As of build enviroment – yes it is true that developers need to have slightly more testing libraries then everyone else but there is a difference between having sane number of versions from VCS (I use Vala daily builds from svn for daily coding) and having even 5 packages but which you have no knowledge about (like metacity, gnome-shell, mutter etc. just to update gobject-introspection to update gtk+).
Some similar NSS problem came up here when building on x86-32. I made a patch which seems to fix compilation but gave up on the whole building when hitting the GIR –strip-prefix problem. The NSS patch is uploaded at http://pastebin.com/A2a30PxH
Btw. regarding jhbuild building lots of system-provided libs: maybe someone could pick up the work described at http://blogs.gnome.org/johncarr/2009/07/15/im-not-afraid-of-people-using-jhbuild/
So, who’s going to step in and add to jhbuild the ability to skip packages that can be installed from the distribution instead of building them from source? ;-)
This would remove most non-GNOME issues, and make your list much shorter…
Yep, the GNOME development environment sucks. My goal is to help GNOME provide a first class development environment – JHBuild works first time, every time, everywhere. It isn’t easy.
For JHBuild using system devel packages some info in this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=564373
My blog is full of JHBuild ‘no fun’ too.
http://gnomedeveloper.blogspot.com/
Pingback: Vincent Untz: My love for jhbuild | Gnu Architecture
Pingback: Diego Escalante Urrelo: How to use jhbuild, the easy way | Gnu Architecture
My main problem with building gnome is really the use of version number based pkg-config. I think that if (as per the autotools philosophy) modules used feature tests, the dependency hell would be lessened. There is a real problem with version number inflation: on package ups its requirent, and in an instant you have to rebuild everything. I have actually taken to using http://www.pkgsrc.org/ to avoid fixing every module – especially as .m4 patches seem not to be accepted as readily as others…