EGLIBC: Not a fork, but a glibc distribution

The GNU C library (or glibc) is a fundamental component of the Linux operating system. It provides much of the user-space interface to the kernel as well as a sizable portion of the utility routines that are used by virtually all Linux applications. A variant of glibc—known as Embedded glibc or EGLIBC—is not very well known outside of the embedded space, but that looks to be changing with the announcement that Debian will switch from glibc to EGLIBC.

The project is quick to point out that it is not a fork of glibc as it aims for compatibility—both source and binary—with glibc. Instead, EGLIBC is like a distribution of glibc, adding patches to fix problems as well as making it easier to use for embedded applications. It also adds support for embedded architectures that are not part of the focus of core glibc development.

The project—started in 2006—is being spearheaded by CodeSourcery, which provides compilers and other development tools based on GCC to its customers. Chief Sourceror Mark Mitchell says that CodeSourcery provides administrative support for the project and "leadership, but not control". Its customers are embedded Linux distributors along with hardware manufacturers and EGLIBC arose from those customers looking for smaller C library solutions.

Mitchell said those customers were looking at uClibc as an alternative to glibc, but using uClibc has some disadvantages because it takes "real work getting applications that work with glibc to work with uClibc". Because of the universal use of glibc, "the Linux that you run on a supercomputer and the Linux that you run on a cell phone are very similar". One of the key advantages of uClibc, though, is its customizability, so that embedded developers can turn off features—Mitchell's classic example is NIS—that are not needed for the product.

That led to adding "option groups" to EGLIBC, which can be enabled or disabled, more-or-less independently to reduce the size of the library. There are roughly 30 option groups currently defined, but the project hopes that new contributors will add new ones. By using the option groups, one can disable things like networking (or just IPv6 networking), math libraries, Sun RPC, Streams, various internationalization/localization options, and more.

Working with glibc maintainer Ulrich Drepper can be difficult due, at least in part, to his blunt manner. While Mitchell is not one to contrast the EGLIBC development community with that of glibc, it is apparent that EGLIBC is trying to be a more inclusive upstream. Others, including Debian's Aurélien Jarno, who announced the switch to EGLIBC, are less reticent, pointing to the difficulty of working with Drepper as a main advantage of EGLIBC.

For his part, Mitchell would like to see a "vibrant open-source community" spring up around EGLIBC, noting that "we welcome all comers". While the project is funded by a consortium of companies: Freescale Semiconductor, MIPS Technologies, MontaVista, and Wind River; one does not need to work for those companies in order to contribute. Nor do the patches need to be focused only on embedded concerns; bug fixes and features that are not accepted by glibc will be considered. Mitchell said that EGLIBC is looking forward to contributions from anyone and, in particular, "are hopeful that Debian will contribute" to the project.

So that any contributions can be rolled back into glibc, EGLIBC requires contributors to assign their copyright to the Free Software Foundation as with a glibc patch. The intent is that the EGLIBC code never stray very far from glibc; in fact, changes to glibc are merged back into EGLIBC frequently. Core glibc development is "focused on x86 and other server-class hardware", Mitchell said, but if that changes, EGLIBC could be merged back into the upstream project. "We'd be happy to see FSF glibc pick up anything we've done, even to the point of obviating EGLIBC", he said.

Jarno is clearly frustrated with how glibc development is done, quoting from the EGLIBC mission statement as part of the announcement: "Encourage cooperation, communication, civility, and respect among developers." But that is not the only advantage to EGLIBC, he lists a number of others including the configurability, a better test suite, and better stable branch handling that makes important bug fixes available for earlier versions.

In a follow up posting to debian-devel, Jarno lists a few more reasons along with answers to some of the questions he has heard. For Debian in particular, supporting many different architectures, including multiple embedded architectures, is very important. He notes that EGLIBC is essentially a drop-in replacement for glibc in keeping with that project's compatibility goals. The common request to add strlcat() and strlcpy()—BSD string handling functions that avoid buffer overruns—will likely not be satisfied for just those compatibility reasons.

EGLIBC clearly offers some things that the standard glibc lacks—not just for embedded developers. The focus on being inclusive will likely expand the pool of C library hackers, which is something that the current glibc development community is not actively encouraging. With luck, it will also act as a test bed for fixes and features—especially as it gets more exposure and testing via Debian—that may lead to a better glibc down the road. It will be interesting to see if other distributions take the same step that Debian has, and what that might mean for glibc in the future.