Tag Archives: JHBuild

gnome-common deprecation, round 2

tl;dr: gnome-common is deprecated, but will be hanging around for a while. If you care about modernising your build system, migrate to autoconf-archive macros.

This GNOME release cycle (3.18), we plan to do the last ever release of gnome-common. A lot of its macros for deprecated technologies (scrollkeeper?!) have been removed, and the remainder of its macros have found better replacements in autoconf-archive, where they can be used by everyone, not just GNOME.

We plan to make one last release, and people are welcome to depend on it for as long as they like. However, if you want new hotness, port to the autoconf-archive versions of the macros; but please do it in your own time. There will be no flag day port away from gnome-common.

Note that, for example, porting to AX_COMPILER_FLAGS is valuable, but will probably require fixing a number of new compiler warnings in your code due to increased warning flags. We hope this will make your code better in the long run.

There’s a migration guide here: https://wiki.gnome.org/Projects/GnomeCommon/Migration.

We’ve tried to make the transition as easy and smooth as possible, but there will inevitably be hiccups. Please let me know about anything which breaks or doesn’t make sense, or discuss it on the desktop development list thread. First person to complain about -Wswitch-enum gets a prize.

For developers

When building from a tarball of a module which uses the new macros, you will no longer need gnome-common installed. (Although you may not have needed it before.)

When building from git, you will need m4-common or autoconf-archive installed.

JHBuild bootstrap installs m4-common automatically, as does gnome-continuous; so you don’t need to worry about that.

For packagers

In the 3.14.0 release, gnome-common installed some early versions of the autoconf-archive macros which conflicted with what autoconf-archive itself installs. It now has a --[with|without]-autoconf-archive configure option to control this. We suggest that all packagers pass --with-autoconf-archive if (and only if) autoconf-archive is packaged on the distribution. See bug #747920.

m4-common must not be packaged. See its README. m4-common is essentially a caching subset of autoconf-archive.

For continuous integrators

Modules which use the new AX_COMPILER_FLAGS macro gain a new standard --disable-Werror configure flag, which should be used in CI systems (and any other system where spurious compiler warnings should not cause total failure of a build) to disable -Werror. The idea here is that -Werror is enabled by default when building from git, and disabled by default when building from release tarballs and in buildbots.

For further discussion

See the thread on the desktop development mailing list.

Statically linking using pkg-config and JHBuild

tl;dr: Export PKG_CONFIG="pkg-config --static" or add it to your .jhbuildrc file.

Statically linking libraries which use libtool (specifically, the LT_INIT autoconf macro) is easy: you pass --enable-static --disable-shared to configure, and out pop static .a libraries instead of dynamic .so libraries.

However, things get more complex once you start to consider dependencies of your library. For example, if I’m statically linking libfoo against libbar, and libbar uses libwidgit internally (i.e. consumes the libwidgit symbols but does not expose any of them as part of libbar’s public interfaces), libfoo needs to know about libwidgit and needs to list it in the libfoo linker command. This is because UNIX archives (statically linked .a files) do not list their dependencies (whereas dynamically linked .so files do (on sensible UNIX platforms, including Linux)). Effectively the transitive closure of link dependencies needs to be resolved at link time, rather than at run time.

How can we cope with this when configuring libfoo? By using pkg-config --static instead of normal pkg-config. This can be achieved by setting the PKG_CONFIG environment variable to pkg-config --static or by adding the following lines to .jhbuildrc (which also set the libtool options mentioned above):

autogenargs = '--disable-shared --enable-static'
os.environ['PKG_CONFIG'] = 'pkg-config --static'

pkg-config’s --static option changes the program’s output to include the Libs.private and (recursively the) Requires.private variables. For example:

$ pkg-config --libs gobject-2.0
-L/opt/gnome3/build/lib64 -lgobject-2.0 -lglib-2.0
$ pkg-config --static --libs gobject-2.0
-pthread -L/opt/gnome3/build/lib64 -lgobject-2.0 -lffi -lglib-2.0

Here, libffi and pthread are both private dependencies of GObject: they’re used internally in GObject, but don’t appear in its external interface. When statically linking against GObject, though, their symbols must be resolved and hence they must appear in the linker command.

For more about the differences between pkg-config’s Libs and Libs.private variables, see the excellent guide to pkg-config. For more information about static linking with pkg-config, see the Autotools Mythbuster.

(There are probably errors or omissions in this post, since I’m nowhere near an expert on linking. Please comment with any corrections! Also, this is not meant to suggest that statically linking libraries is a good idea in general — there are only a few situations where it’s sensible. But for those situations, hopefully this post makes things a little easier.)

Colourful GCC output

For a long time, I’ve used colorgcc as a way to highlight warnings and errors in GCC output. It’s worked wonderfully, but today Travis pointed out that GCC has grown an option to enable colourised output: -fdiagnostics-color. This will be available in GCC 4.9, but the patch seems to have been backported to Fedora 19 so that more people can join in the fun.

This means I can throw away colorgcc from my .jhbuildrc:

os.environ['CC'] = '/usr/bin/color-gcc'

and enable -fdiagnostics-color:

os.environ['CFLAGS'] += ' -fdiagnostics-color=auto'

Even better, adding the following snippet to configure.ac in a standard automake project will automatically enable colourised compiler output if the compiler (is GCC and) supports it:

                 [AM_CFLAGS="$AM_CFLAGS -fdiagnostics-color=auto"])

(In actual fact, I used ERROR_CFLAGS for this in folks, to keep unrelated CFLAGS separated, but that’s an implementation detail of folks’ build system.)