What it is

gnulib is one of the ways GNU software deals with unixes that don't use glibc as their C library runtime. It provides stubs for projects that use function that aren't universally available.

Similar to this was libiberty, which had much the same goal, but is now pretty much just used by gcc and binutils.

Why it's bad

The reason why it's a terrible idea is that it isn't a library that you compile and link to, it's a bunch of C source code that you link into your source tree at build time and statically link into your executable.

A plethora of tags

It can't become a library because it's interface is too unstable, everything that uses it relies on a specific version, otherwise it's likely to break. Just look at the list of tags in its repository.

git ls-remote git://git.savannah.org/gnulib.git will show you every branch and tag they have. We mirrored gnulib for baserock, so you can also see it at git://git.baserock.org/delta/gnulib.git.


It's usually included in a project as a git submodule, since this ensures that the right version of gnulib is used, and as part of bootstrapping the source code from version control, the ./bootstrap script clones the submodule (or just plain clones the repository if the source code isn't maintained in git).

After this it copies or symlinks any "modules" you requested, modules meaning random bits of source code you want to re-use.

Worse is something depending on gnulib being installed, which I have seen, but can't recall off the top of my head where.

Unversioned translations

Unless you tell it --skip-po, it will download translations at build time from http://translationproject.org, which leaves you with the problem that these translations aren't version controlled.

This causes problems for continuous integration, since your builds can fail independently to your source code, because the translations are broken, or the server hosting them is down.

This makes projects that use gnulib difficult to build only from the contents of version control, which causes unnecessary friction, since the developers are still working on the tarball release model, which with today's version control, is an antiquated model.


If you want such a compatibility library I would recommend you try glib instead. Gnulib is harder to integrate into your build-system than a dependency on GLib.

An aside

Another issue I have with gnulib is its commit history. If you're not careful, a clone of gnulib can be huge, since every change is entered in its changelog, unless you tell git to repack, it will store a million slightly different changelog files of ever increasing size.

We stopped needing Changelogs when version control was invented.

This can compress quite nicely, but you've got to remember to do so. Before our source import tool was told to repack git mirrors, gnulib had a disk footprint on the same order of magnitude to the linux kernel.

Also, the repack had to be told to limit the amount of memory it used, since it would easily exhaust the system't resources and die because it couldn't allocate enough memory.