Fork and variant

In 1994, the developers of the Linux kernel forked glibc. Their fork, "Linux libc", was maintained separately until around 1998. Because the copyright attribution was insufficient, changes could not be merged back to the GNU Libc.^[19] When the FSF released glibc 2.0 in January 1997, the kernel developers discontinued Linux libc due to glibc 2.0's superior compliance with POSIX standards.^[20] glibc 2.0 also had better internationalisation and more in-depth translation, IPv6 capability, 64-bit data access, facilities for multithreaded applications, future version compatibility, and the code was more portable.^[21] The last-used version of Linux libc used the internal name (soname) libc.so.5. Following on from this, glibc 2.x on Linux uses the soname libc.so.6^{[22][better source needed]}

In 2009, Debian and a number of derivatives switched from glibc to the variant^[24] eglibc.^[25] Eglibc was supported by a consortium consisting of Freescale, MIPS, MontaVista and Wind River.^[26] It contained changes that made it more suitable for embedded usage and had added support for architectures that were not supported by glibc, such as the PowerPC e500. The code of eglibc was merged back into glibc at version 2.20.^[27] Since 2014, eglibc is discontinued. The Yocto Project and Debian also moved back to glibc since the release of Debian Jessie.^[28]

Steering committee

Starting in 2001 the library's development had been overseen by a committee,^[29] with Ulrich Drepper^[30] kept as the lead contributor and maintainer. The steering committee installation was surrounded by a public controversy, as it was openly described by Ulrich Drepper as a failed hostile takeover maneuver by Richard Stallman.^{[31][32][33][34]}

In March 2012, the steering committee voted to disband itself and remove Drepper in favor of a community-driven development process, with Ryan Arnold, Maxim Kuvyrkov, Joseph Myers, Carlos O'Donell, and Alexandre Oliva holding the responsibility of GNU maintainership (but no extra decision-making power).^[35][36][37]

Supported hardware and kernels

glibc is used in systems that run many different kernels and different hardware architectures. Its most common use is in systems using the Linux kernel on x86 hardware, however, officially supported hardware^[38] includes: ARM, ARC, C-SKY, DEC Alpha, IA-64, Motorola m68k, MicroBlaze, MIPS, Nios II, PA-RISC, PowerPC, RISC-V, s390, SPARC, and x86 (old versions support TILE). It officially supports the Hurd and Linux kernels. Additionally, there are heavily patched versions that run on the kernels of FreeBSD and NetBSD (from which Debian GNU/kFreeBSD and Debian GNU/NetBSD systems are built, respectively), as well as a forked-version of OpenSolaris.^[39] It is also used (in an edited form) and named libroot.so in BeOS and Haiku.^[40]

Use in small devices

glibc has been criticized as being "bloated" and slower than other libraries in the past, e.g. by Linus Torvalds^[41] and embedded Linux programmers. For this reason, several alternative C standard libraries have been created which emphasize a smaller footprint. However, many small-device projects use GNU libc over the smaller alternatives because of its application support, standards compliance, and completeness. Examples include Openmoko^[42] and Familiar Linux for iPaq handhelds (when using the GPE display software).^[43]

Secure string functions

glibc does not implement bounds-checking interfaces defined in C11 and did not implement strlcpy and strlcat^[44][45] until 2023 on the grounds that "in practice these functions can cause trouble, as their intended use encourages silent data truncation, adds complexity and inefficiency, and does not prevent all buffer overruns in the destinations."^[46] The FAQ pointed out that the bounds-checking interfaces were optional in the ISO standard and that snprintf was available as an alternative.^[46]