glibc

En 1994, los desarrolladores del kernel de Linux bifurcaron glibc. Su bifurcación, "Linux libc", se mantuvo por separado hasta alrededor de 1998. Debido a que la atribución de derechos de autor era insuficiente, los cambios no pudieron fusionarse de nuevo con GNU Libc. ^{[ 20 ]} Cuando la FSF publicó glibc 2.0 en enero de 1997, los desarrolladores del kernel descontinuaron Linux libc debido a la mayor conformidad de glibc 2.0 con los estándares POSIX. ^{[ 21 ]} glibc 2.0 también tenía mejor internacionalización y traducción más profunda, capacidad IPv6 , acceso a datos de 64 bits, facilidades para aplicaciones multihilo, compatibilidad con versiones futuras y el código era más portable. ^{[ 22 ]} La última versión utilizada de Linux libc usaba el nombre interno ( soname ) libc.so.5 . A partir de esto, glibc 2.x en Linux usa el soname libc.so.6 ^{[ 23 ]}

En 2009, Debian y varios derivados cambiaron de glibc a la variante ^{[ 25 ]} eglibc. ^{[ 26 ]} Eglibc fue respaldada por un consorcio formado por Freescale , MIPS , MontaVista y Wind River . ^{[ 27 ]} Contenía cambios que la hacían más adecuada para su uso en sistemas embebidos y había añadido soporte para arquitecturas que no eran compatibles con glibc, como el PowerPC e500 . El código de eglibc se fusionó de nuevo con glibc en la versión 2.20. ^{[ 28 ]} Desde 2014, eglibc está descontinuada. El Proyecto Yocto y Debian también volvieron a glibc desde el lanzamiento de Debian Jessie . ^{[ 29 ]}

A partir de 2001, el desarrollo de la biblioteca fue supervisado por un comité, ^{[ 30 ]} con Ulrich Drepper ^{[ 31 ]} como principal colaborador y mantenedor. La instalación del comité directivo estuvo rodeada de controversia pública, ya que Ulrich Drepper la describió abiertamente como una maniobra fallida de adquisición hostil por parte de Richard Stallman . ^{[ 32 ] [ 33 ] [ 34 ] [ 35 ]}

En marzo de 2012, el comité directivo votó a favor de disolverse y eliminar a Drepper en favor de un proceso de desarrollo impulsado por la comunidad, con Ryan Arnold, Maxim Kuvyrkov, Joseph Myers, Carlos O'Donell y Alexandre Oliva asumiendo la responsabilidad del mantenimiento de GNU (pero sin poder de decisión adicional). ^{[ 36 ] [ 37 ] [ 38 ]}

glibc se utiliza en sistemas que ejecutan muchos kernels y arquitecturas de hardware diferentes . Su uso más común es en sistemas que utilizan el kernel de Linux en hardware x86 , sin embargo, el hardware oficialmente compatible ^{[ 39 ]} incluye: ARM , ARC , C-SKY , DEC Alpha , IA-64 , Motorola m68k , MicroBlaze , MIPS , Nios II , PA-RISC , PowerPC , RISC-V , s390 , SPARC y x86 (las versiones antiguas admiten TILE ). Admite oficialmente los kernels Hurd y Linux . Además, hay versiones fuertemente parcheadas que se ejecutan en los kernels de FreeBSD y NetBSD (a partir de los cuales se construyen los sistemas Debian GNU/kFreeBSD y Debian GNU/NetBSD , respectivamente), así como una versión bifurcada de OpenSolaris . ^{[ 40 ]} También se utiliza (en una forma editada) y se llama libroot.so en BeOS y Haiku . ^{[ 41 ]}

glibc ha sido criticada por ser " excesiva " y más lenta que otras bibliotecas en el pasado, por ejemplo, por Linus Torvalds ^{[ 42 ]} y programadores de Linux embebido . Por esta razón, se han creado varias bibliotecas estándar C alternativas que priorizan un tamaño menor. Sin embargo, muchos proyectos para dispositivos pequeños utilizan GNU libc en lugar de las alternativas más pequeñas debido a su compatibilidad con aplicaciones, cumplimiento de estándares y exhaustividad. Algunos ejemplos son Openmoko ^{[ 43 ]} y Familiar Linux para dispositivos portátiles iPaq (cuando se utiliza el software de visualización GPE ). ^{[ 44 ]}

glibc no implementa las interfaces de comprobación de límites definidas en C11 y no implementó strlcpy y strlcat ^{[ 45 ] [ 46 ]} hasta 2023 con el argumento de que "en la práctica, estas funciones pueden causar problemas, ya que su uso previsto fomenta el truncamiento silencioso de datos, añade complejidad e ineficiencia y no evita todos los desbordamientos de búfer en los destinos". ^{[ 47 ]} Las FAQ señalaron que las interfaces de comprobación de límites eran opcionales en el estándar ISO y que snprintf estaba disponible como alternativa. ^{[ 47 ]}