De Wikipedia, la enciclopedia libre
  (Redirigido desde Glibc )
Saltar a navegación Saltar a búsqueda

La API de Linux se compone de la interfaz de llamada al sistema del kernel de Linux, la biblioteca GNU C (de GNU ), libdrm , libalsa y libevdev (de freedesktop.org ).
La biblioteca GNU C es un contenedor de las llamadas al sistema del kernel de Linux .
El kernel de Linux y la biblioteca GNU C juntos forman la API de Linux . Después de la compilación, los binarios ofrecen una ABI .

La biblioteca C de GNU , comúnmente conocida como glibc , es el Proyecto GNU aplicación de la 's biblioteca estándar C . A pesar de su nombre, ahora también es compatible directamente con C ++ (e, indirectamente, con otros lenguajes de programación ). Fue iniciado en la década de 1980 por la Free Software Foundation (FSF) para el sistema operativo GNU .

Lanzado bajo la GNU Lesser General Public License , [3] glibc es un software libre . El proyecto de la biblioteca GNU C proporciona las bibliotecas centrales para el sistema GNU y los sistemas Linux, así como para muchos otros sistemas que usan Linux como núcleo . Estas bibliotecas proporcionan API críticas, incluidas ISO C11 , POSIX.1-2008 , BSD , API específicas del sistema operativo y más. Estas API incluyen instalaciones fundamentales como abrir , leer , escribir , malloc , printf , getaddrinfo ,dlopen , pthread_create , crypt , login , exit y más.

Historia [ editar ]

El proyecto glibc fue inicialmente escrito principalmente por Roland McGrath , que trabajaba para la Free Software Foundation (FSF) en la década de 1980 cuando era adolescente. [4]

En febrero de 1988, describe FSF glibc como habiendo casi completado la funcionalidad requerida por ANSI C . [5] Para 1992, tenía las funciones ANSI C-1989 y POSIX.1-1990 implementadas y se estaba trabajando en POSIX.2. [6]

En septiembre de 1995 Ulrich Drepper hizo su primera contribución al proyecto glibc y durante la década de 1990 se convirtió gradualmente en el principal contribuyente y mantenedor de glibc. [7] Drepper ocupó el puesto de mantenimiento durante muchos años y hasta 2012 acumuló el 63% de todos los compromisos con el proyecto. [8]

Libc de Linux [ editar ]

A principios de la década de 1990, los desarrolladores del kernel de Linux bifurcaron glibc. Su bifurcación, "Linux libc", se mantuvo por separado.

Cuando la FSF lanzó glibc 2.0 en enero de 1997, los desarrolladores del kernel descontinuaron Linux libc debido al cumplimiento superior de glibc 2.0 con los estándares POSIX. [9] glibc 2.0 también tuvo una mejor internacionalización y una traducción más profunda, capacidad IPv6 , acceso a datos de 64 bits, instalaciones para aplicaciones multiproceso, compatibilidad con versiones futuras y el código era más portátil. [10]

La última versión usada de Linux libc usó el nombre interno ( soname ) libc.so.5 . Después de esto, glibc 2.x en Linux usa el soname libc.so.6 [11] (las arquitecturas Alpha e IA64 ahora usan libc.so.6.1 , en su lugar). El nombre del archivo * .so a menudo se abrevia como libc6 (por ejemplo, en el nombre del paquete en Debian ) siguiendo las convenciones normales para las bibliotecas.

Según Richard Stallman , la FSF no pudo fusionar los cambios realizados en Linux libc en glibc debido a una autoría vaga. El proyecto GNU es bastante estricto sobre la grabación de derechos de autor y autores. [12]

Instalación de un comité directivo [ editar ]

A partir de 2001, el desarrollo de la biblioteca había sido supervisado por un comité, [13] con Ulrich Drepper [14] como contribuyente y mantenedor principal. La instalación del comité directivo estuvo rodeada de una controversia pública, ya que Ulrich Drepper la describió abiertamente como una maniobra de adquisición hostil fallida de Richard Stallman. [15] [16] [17]

Migrado a Git, un VCS distribuido [ editar ]

Aunque anteriormente estaba en un repositorio de CVS , en 2009 glibc se migró a un repositorio de Git (un sistema de control de versiones distribuido) en Sourceware . [18]

Debian cambia a EGLIBC y viceversa [ editar ]

Después de largas controversias en torno al estilo de liderazgo de Drepper y la aceptación de la contribución externa, [19] [20] [21] Debian cambió públicamente a la bifurcación glibc EGLIBC en 2009 [22] y volvió a glibc con la versión Debian 8.0 (Jessie) en abril de 2015. [23]

El comité directivo se disuelve [ editar ]

En marzo de 2012, el comité directivo votó para disolverse y destituir a Drepper a 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 adicional de toma de decisiones). [24] [25]

Después del cambio en el mantenimiento de glibc, Debian y otros proyectos que se habían cambiado a alternativas volvieron a migrar a glibc. [26] Desde principios de 2014, la bifurcación glibc EGLIBC ya no se está desarrollando ya que sus "objetivos ahora se están abordando directamente en GLIBC".

En julio de 2017, 30 años después de comenzar con glibc, Roland McGrath anunció su partida, "declarándome mantenedor emérito y retirándome de la participación directa en el proyecto. Estos últimos meses, si no los últimos años, han demostrado que no me necesita más ". [4]

Historial de versiones [ editar ]

Para la mayoría de los sistemas, la versión de glibc se puede obtener ejecutando el archivo lib (por ejemplo, /lib/libc.so.6).

Funcionalidad [ editar ]

glibc proporciona la funcionalidad requerida por la Especificación Única de UNIX , POSIX (1c, 1d y 1j) y algunas de las funcionalidades requeridas por las interfaces ISO C11 , ISO C99 , Berkeley Unix (BSD), la Definición de Interfaz del Sistema V (SVID) y la X / Open Portability Guide (XPG), edición 4.2, con todas las extensiones comunes a los sistemas compatibles con XSI ( X / Open System Interface ) junto con todas las extensiones X / Open UNIX.

Además, glibc también proporciona extensiones que se han considerado útiles o necesarias durante el desarrollo de GNU .

Hardware y kernels compatibles [ editar ]

glibc se utiliza en sistemas que ejecutan muchos kernels y arquitecturas de hardware diferentes . Su uso más común es en sistemas que usan el kernel de Linux en hardware x86 , sin embargo, el hardware oficialmente soportado [42] incluye: ARM de 32 bits y su ISA de 64 bits más nuevo (AArch64) , C-SKY , DEC Alpha , IA-64 , Motorola m68k , MicroBlaze , MIPS , Nios II , PA-RISC , PowerPC , RISC-V , s390 , SPARC yx86 (las versiones anteriores admiten TILE ). Es compatible oficialmente con los kernels de Hurd y Linux . Además, hay versiones muy parcheadas que se ejecutan en los núcleos 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 . [43] También se utiliza (en una forma editada) y se denomina libroot.so en BeOS y Haiku . [44]

Usar en dispositivos pequeños [ editar ]

glibc ha sido criticado por ser " inflado " y más lento que otras bibliotecas en el pasado, por ejemplo, por Linus Torvalds [45] y programadores de Linux embebidos . Por esta razón, se han creado varias bibliotecas estándar de C alternativas que enfatizan una huella más pequeña. Sin embargo, muchos proyectos de dispositivos pequeños utilizan GNU libc sobre las alternativas más pequeñas debido a su compatibilidad con aplicaciones, cumplimiento de estándares e integridad. Los ejemplos incluyen Openmoko [46] y Familiar Linux para dispositivos portátiles iPaq (cuando se usa el software de visualización GPE ). [47]

Capas de compatibilidad [ editar ]

Hay capas de compatibilidad (" shims ") que permiten que los programas escritos para otros ecosistemas se ejecuten en sistemas de oferta de interfaz glibc. Estos incluyen libhybris , una capa de compatibilidad para Bionic y Wine de Android , que puede verse como una capa de compatibilidad desde las API de Windows hasta glibc y otras API nativas disponibles en sistemas similares a Unix.

Ver también [ editar ]

  • Gnulib
  • API del kernel de Linux

Referencias [ editar ]

  1. ^ Corbet, Jonathan (28 de marzo de 2012). "Un punto de inflexión para GNU libc" . LWN.net.
  2. ^ Adhemerval Zanella (1 de febrero de 2021). "La versión 2.33 de la biblioteca GNU C ya está disponible" (lista de correo) . Consultado el 2 de febrero de 2020 .
  3. ^ a b "sourceware.org Git - glibc.git / blob - COPYING.LIB" . sourceware.org . Consultado el 13 de septiembre de 2017 .
  4. ^ a b "Roland McGrath se retira como mantenedor de glibc [LWN.net]" . lwn.net . El 7 de julio de 2017 . Consultado el 8 de julio de 2017 .
  5. ^ "Boletín de GNU, vol. 1 no. 4, febrero de 1988" . La mayoría de las bibliotecas están listas. Roland McGrath […] tiene un conjunto casi completo de funciones de biblioteca ANSI C. Esperamos que estén listos en algún momento de esta primavera.
  6. ^ "Boletín de GNU, vol. 1 no. 12" . Ahora contiene todas las funciones ANSI C-1989 y POSIX.1-1990, y se está trabajando en las funciones POSIX.2 y Unix (BSD y System V)
  7. ^ registro de cambios glibc en GitHub .
  8. ^ Corbet, Jonathan (28 de marzo de 2012). "Un punto de inflexión para GNU libc" . LWN.net. De las casi 19.000 confirmaciones encontradas en el repositorio de git del proyecto (que contiene cambios desde 1995), Ulrich realizó más de 12.000.
  9. ^ "Bifurcación: incluso te puede pasar a ti" . 12 de septiembre de 2008. la división entre GNU LIBC y Linux LIBC - continuó durante años mientras Linux se estabilizaba, y luego las bifurcaciones se volvieron a fusionar en un solo proyecto
  10. ^ Lee, Elliot (2001). "Una comparación técnica de glibc 2.x con bibliotecas de sistema heredadas" . Archivado desde el original el 11 de abril de 2004.
  11. ^ "Ensayo sobre el miedo a la bifurcación, ver" 6. glibc -> Linux libc -> glibc " " .
  12. ^ "Miedo a la bifurcación, nota al pie de los comentarios de fusión de Stallman" .
  13. ^ "página de inicio de glibc" . En 2001, se formó el Comité Directivo de la Biblioteca GNU C…, y actualmente está integrado por Mark Brown, Paul Eggert, Andreas Jaeger, Jakub Jelinek, Roland McGrath y Andreas Schwab.
  14. ^ "Ulrich Drepper" . LinkedIn . Consultado el 13 de junio de 2012 .
  15. ^ Drepper, Ulrich (26 de junio de 2000). "RMS está de nuevo" . sourceware.org . Consultado el 20 de noviembre de 2015 .Hace unas semanas, RMS inició el siguiente ataque contra mí (un solo correo, seguido de intentos indirectos de tomar influencia, seguido de otro correo hoy). La esencia es que se queja de que no estoy siguiendo las "políticas de GNU" y, por lo tanto, tengo que ser reemplazado por un comité directivo del que podría formar parte. Algunos de ustedes (a saber, Roland y Andreas S.) probablemente sepan esto ya que él propuso a ambos como otros miembros del comité. Además, estaba Mark Brown en la lista (conozco a alguien con este nombre en IBM que también encajaría en este grupo, pero no estoy seguro de si realmente es él). De todos modos, rechazo esto por completo. No está ayudando en absoluto, es todo lo contrario. Primero, no tengo conocimiento de ninguna política esencial que esté violando. Los únicos son que yo 'No estoy siguiendo órdenes de RMS que claramente tienen intenciones políticas (lo que por supuesto es un sacrilegio) y posiblemente que no me importa Winblowz (si es que esto último cuenta). Nada de esto cambiará de ninguna manera.
  16. ^ Drepper, Ulrich (15 de agosto de 2001). "glibc 2.2.4" . sourceware.com . Consultado el 29 de noviembre de 2015 . Y ahora algunas cosas no tan bonitas. Stallman intentó recientemente lo que yo llamaría una toma de control hostil del desarrollo de glibc. Trató de conspirar a mis espaldas y persuadir a los otros desarrolladores principales para que tomen el control para que al final él tenga el control y pueda dictar lo que le plazca. Este intento falló, pero siguió presionando a la gente en todas partes y se puso realmente feo. Al final acepté la creación de un llamado "comité de dirección" (SC).
  17. ^ rms-acusado-de-intentar-glibc-hostile-takeover en slashdot .com el 19 de agosto de 2001
  18. ^ glibc repositorio en Sourceware.com
  19. ^ Ulrich Drepper 2007-10-03 06:13:55 UTC "Esto no tiene nada que ver con" solo x86 ". Todas las ABI diseñadas por personas que tienen un poco de comprensión no requieren cambios. Cualquier cambio tendrá un impacto negativo en las arquitecturas bien diseñadas para el único beneficio de esta basura incrustada. Pero su propia versión del archivo en el complemento ".
  20. ^ Drepper, Ulrich (25 de mayo de 2005). "Dictadura de las Minorías" . udrepper.livejournal.com . Consultado el 15 de enero de 2012 .¿Qué arquitecturas vale la pena apoyar? […]. No solo tenemos que buscar el soporte de irrelevancia (qué porcentaje se preocupa por Vax, PArisc), también tenemos que mirar el nivel de complejidad adicional que requiere el soporte. Algunas ABI simplemente se definen deliberadamente para ser diferentes de otras (ver IA-64), lo que requiere una gran cantidad de esfuerzo. También hay capacidades significativamente divergentes (por ejemplo, la falta de operaciones atómicas en demasiadas arquitecturas). Esto con demasiada frecuencia provoca un código innecesariamente paralizado, ya que escribir código de una manera que permita un uso óptimo en todas las situaciones es muy difícil. La solución debe ser restringir el soporte a solo un puñado de arquitecturas que son compatibles con el proyecto. Todos los demás apoyos deben ocurrir fuera del árbol y, por lo tanto, todo el trabajo debe ser realizado por los grupos de intereses especiales.No quiero decir que sigamos todos estos puntos a la perfección, pero para un gran proyecto, glibc ciertamente se acerca más a esto.
  21. ^ Jarno, Aurélien (5 de mayo de 2009). "Debian está cambiando a EGLIBC" . aurel32.net . Consultado el 15 de enero de 2012 . Upstream más amigable (especialmente con respecto a las arquitecturas integradas): “Fomente la cooperación, la comunicación, la cortesía y el respeto entre los desarrolladores” (en contraposición a esto).
  22. timothy (6 de mayo de 2009). "Debian cambiando de Glibc a Eglibc" . Slashdot . Consultado el 14 de enero de 2012 .
  23. ^ Registro de cambios del paquete Debian
  24. ^ McGrath, Roland (26 de marzo de 2012). "disolución del comité directivo de glibc" . Sourceware.org . Consultado el 13 de junio de 2012 .
  25. ^ Myers, Joseph S. (26 de marzo de 2012). "Desarrollo y mantenimiento de la biblioteca GNU C" . Sourceware.org . Consultado el 13 de junio de 2012 .
  26. ^ "Debian está cambiando (de nuevo) a GLIBC" . Aurélien. 19 de junio de 2014 . Consultado el 19 de junio de 2014 .
  27. ^ "CosmicCuttlefish / ReleaseNotes - Wiki de Ubuntu" .
  28. ^ "Capítulo 5. RHEL 8.0.0 versión Red Hat Enterprise Linux 8" .
  29. ^ "Capítulo 2. Novedades de Debian 10" .
  30. ^ "Cambios / GLIBC228" .
  31. ^ "Red Hat Bugzilla - Error 1598403" .
  32. ^ "sourceware.org Git - glibc.git / blob - NOTICIAS" .
  33. ^ "DiscoDingo / ReleaseNotes - Wiki de Ubuntu" .
  34. ^ "Cambios / GLIBC229" .
  35. ^ "Red Hat Bugzilla - Error 1653403" .
  36. ^ "sourceware.org Git - glibc.git / blob - NOTICIAS" .
  37. ^ "EoanErmine / ReleaseNotes - Wiki de Ubuntu" .
  38. ^ "Cambios / GLIBC230" .
  39. ^ "Focal (20.04): paquete glibc: Ubuntu" .
  40. ^ "Cambios / GLIBC231" .
  41. ^ "La versión 2.32 de la biblioteca GNU C ya está disponible" . sourceware.org . Consultado el 13 de agosto de 2020 .
  42. ^ "Los mantenedores de máquinas de la biblioteca GNU C" .
  43. ^ Bartley, David; Spang, Michael. "GNU / kOpenSolaris (GNU libc / base + núcleo de OpenSolaris)" . Consultado el 16 de diciembre de 2008 .
  44. ^ "Fuente Haiku" . libroot.so no forma parte del proyecto GNU y está incluido en el código fuente de Haiku.
  45. ^ Torvalds, Linus (9 de enero de 2002). "Publicando en la lista de correo glibc" .
  46. ^ "Componentes de OpenMoko" . Usaremos glibc (no uClibC)… Las alternativas pueden ahorrar más espacio y estar más optimizadas, pero es más probable que nos den problemas de integración.
  47. ^ "Re: [Familiar] ¿Qué glibc para Familiar 0.8.4?" . Pregunta: ¿Qué versión de GLIBC se usó para construir el Familiar 0.8.4? Respuesta: 2.3.3

Enlaces externos [ editar ]

  • Página web oficial