The “Linux libc” fork of the GNU C Library is now a mostly forgotten event. The fork lived from 1994 to 1997/8—just before my time—but I’ve found interesting accounts of it by others.
The main sources of information are:
- Elliot Lee’s essay: A Technical Comparison of glibc 2.x With Legacy System Libraries—the original page is gone but archive.org has a copy
- Rick Moen’s essay: Fear of Forking section 6 discusses this fork
- David A. Wheelers’s footnote: Forking from his “Look at the numbers!” essay
According to Wheeler’s appendix, the fork occurred just after February 1994, and the motivations were procedural/organisational: “the Linux kernel developers thought that the FSF’s development process for the C library was too slow and not responding to their needs”. This ties in with Bruce Perens’ comment in 2000 that the Linux libc fork “went on for years while Linux stabilized” (from the article Forking: it could even happen to you).
Moen’s article says the reason was technical: “they decided that FSF’s library (then at version 1-point-something) could/should best be adapted for the Linux kernel as a separately-maintained project”. Both reasons could have contributed.
During the fork
H. J. Lu is mentioned by a few people as being the maintainer or main contributor to Linux libc.
Elliot Lee’s article says that while the Linux kernel developers were using their fork, glibc development stalled for a time. This coincides with the time that FSF spent working on version 2.0, during which there were no official releases for two years. The development progress during this time is noted in the twice-annual GNU’s bulletins that FSF published throughout the 90s.
From the NEWS files, it seems Cygnus Solutions hired Ulrich Drepper to work on it from late 1995 onwards since the January 1996 GNU’s bulletin mentions that Drepper has contributed a lot “in the last few months”.
By all accounts, glibc-2.0 surpassed Linux libc on features, standards, and code cleanliness. Elliot Lee’s article goes into most detail on this, citing features such as POSIX compliance, internationalisation support, multithreaded support, IPv6, and 64-bit data access, and library version migration support.
There is an 1998 interview with H.J. Lu about libc5 and glibc. The interview mostly focuses on technical differences and the transition. H.J. is quite positive about glibc 2.0.
Bruce Perens’ one line comment about the aftermath is that the projects “re-merged”, however, while the communities and contributors may have merged, according to Stallman, little or no code did. According to Stallman, the Linux libc had insufficient records of authorship or copyright ownership for the code they distributed (something the GNU project has always been very strict about), and the Linux libc maintainers were unwilling to sort this out.
In 1997 through 1998 nearly all GNU/Linux systems switched from libc back to glibc. Red Hat migrated in December 1997, and Debian was planning their migration at that time too, according to Lee. And so ended a story that is now rarely mentioned.