GNU-C-Bibliothek

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
glibc
Heckert GNU white.svg
Basisdaten
Entwickler Free Software Foundation
Aktuelle Version 2.23[1]
(19. Februar 2016)
Betriebssystem Unix, Linux
Kategorie Laufzeitbibliothek
Standardbibliothek
Lizenz LGPL
Deutschsprachig ja
gnu.org/software/libc/

glibc, die GNU C-Bibliothek, ist eine freie Implementierung der C-Standard-Bibliothek, die vom GNU-Projekt zusammen mit der GNU Compiler Collection entwickelt wird.

Die glibc steht unter der LGPL, was den Einsatz der Bibliothek bei nicht freier Software ermöglicht. Die glibc-Bibliothek gehört zu den fundamentalsten und wichtigsten Bibliotheken eines Linux-Betriebssystems.

Eigenschaften[Bearbeiten | Quelltext bearbeiten]

Eines der Designziele der glibc ist Portabilität über verschiedene Softwareplattformen, daher ist sie auch für eine Reihe von Betriebssystemen verfügbar. Einige Betriebssysteme, darunter GNU/Linux, benutzen die glibc als ihre offizielle Standard-C-Bibliothek. Die Bibliotheken der glibc sind selbst zum größten Teil auch in C geschrieben, laufzeitkritische Routinen verwenden jedoch Assembler-Code.

Funktionalität[Bearbeiten | Quelltext bearbeiten]

Die glibc stellt die in der Single UNIX Specification, POSIX (1c, 1d, und 1j) geforderte Funktionalität bereit, zusätzlich Teile der ISO C99, Berkeley Unix (BSD) Interface, der System V Interface Definition (SVID) und der X/Open Portability Guide (XPG), Issue 4.2, mit allen Erweiterungen üblich für XSI-(X/Open System Interface)-konforme Systeme mit allen X/Open-Unix-Erweiterungen.

Zusätzlich zu den von den C-Standards geforderten Funktionen bietet sie auch eine Reihe von (nicht standardisierten) Erweiterungen.

Kritik[Bearbeiten | Quelltext bearbeiten]

Ihre Universalität und ihr gleichzeitiger Fokus auf die x86-Hardware-Plattform[2][3] ist gleichzeitig aber auch der größte Kritikpunkt an der glibc. Durch die Menge des einzubindenden Codes werden gegen die glibc gelinkte Programme unnötig groß[4] und damit potenziell langsam, andere Plattformen werden gar nicht unterstützt. Eine Reihe von Projekten hat sich daher der Idee verschrieben, Alternativen zu glibc zu entwickeln, die bekanntesten sind uClibc und diet libc. Durch Beschränkung auf die – aus Sicht der Kritiker – „wesentlichen Dinge“ sind diese Implementierungen deutlich kleiner für die fertigen Binärprogramme, allerdings lässt sich nicht jedes glibc-Programm auch gegen diese alternativen Bibliotheken linken (z. B. weil sie Funktionen der glibc benutzen, die in den anderen Bibliotheken fehlen), oder es verhält sich während der Ausführung unerwartet. Vor allem für eingebettete Systeme sind die schlanken libc-Implementierungen jedoch sinnvoll.

Geschichte[Bearbeiten | Quelltext bearbeiten]

Maintainer[Bearbeiten | Quelltext bearbeiten]

Seit 2001 wurde das CVS-Repository der glibc bei Red Hat gehostet und fast ausschließlich von Ulrich Drepper gepflegt (Maintainer).[5] Zusätzlich wurden aktuelle Snapshots in den FTP-Archiven und deren Spiegelserver bereitgestellt. Damit kam man der Community entgegen, da man z. B. durch restriktive Firewalls nicht von überall aus per CVS auf das Internet zugreifen kann.

Um das Jahr 2001 wurde ein Lenkungsausschuss für das glibc-Projekt eingerichtet[6], um welches es öffentlich ausgetragene Kontroversen gab. Ulrich Drepper beschrieb die Vorgänge öffentlich als Versuch einer "feindlichen Übernahme" (engl. "hostile takeover") durch Richard Stallman, welche fehlgeschlagen war.[7][8][9]

Beginnend mit 2009 wird die glibc als Git-Repository bei Sourceware weiter gepflegt.[10]

glibc 2.3[Bearbeiten | Quelltext bearbeiten]

Mit der glibc 2.3 wurde eine Reihe von Verbesserungen integriert, die wichtigste davon ist die Ersetzung der alten Linux-Threading-Erweiterung linuxthreads durch die Native POSIX Thread Library (NPTL), die ebenso wie die glibc selbst federführend bei Red Hat entwickelt wurde. Die NPTL ermöglicht in Zusammenarbeit ab dem Linux-Kernel 2.6 eine deutliche Leistungssteigerung beim Threading und ist dabei POSIX-konform. Da man abwärtskompatibel sein wollte, steht für Programme, die auf nicht POSIX-konforme Verhaltensweisen der alten Implementation angewiesen sind, auch weiter LinuxThreads zur Verfügung, man muss es nun aber explizit per Linker-Direktive anfordern (z. B. LD_ASSUME_KERNEL=2.4.22). Auch die glibc selbst ist in den wichtigsten Funktionen abwärtskompatibel. Der kleinste gemeinsame Nenner ist dabei die Funktionalität der libc6, weshalb die Bezeichnungen glibc und libc6 auch häufig synonym füreinander verwendet werden (auf Alpha- und IA-64-Architekturen heißen die Bibliotheken aus historischen Gründen libc6.1, bieten jedoch die gleiche Funktionalität).

EGLIBC-Fork[Bearbeiten | Quelltext bearbeiten]

Wegen eines fehlenden Fokus der glibc auf Kompatibilität mit eingebetteten Systemen[3], besonders ARM-Prozessoren, und Problemen mit dem Umgang des Projektverantwortlichen, Ulrich Drepper, bei Fehlerberichten und eingereichten Korrekturen wurde eine Abspaltung (fork) des Projekts namens EGLIBC erstellt.[11] Nach Selbsteinschätzung der Entwickler handelt es sich bei eglibc jedoch nicht um einen klassischen Fork, vielmehr wollen die Entwickler die Änderungen von glibc übernehmen, aber auch Patches akzeptieren, die keinen Einzug in glibc gefunden haben.[12] Damit verfolgt eglibc das Ziel, einen freundlicheren Umgang mit Entwicklern zu pflegen und Embedded-Prozessoren besser zu unterstützen. Als erste große Linux-Distribution hat Debian auf diese Implementierung umgestellt, wechselte aber im Juni 2014 wieder zurück zu glibc, da das EGLIBC-Projekt seine Mission als erfüllt ansah und sich auflöste.[13][14][15] Ubuntu verwendet seit Version 9.10 EGLIBC.[16]

Versionsgeschichte[Bearbeiten | Quelltext bearbeiten]

Die Veröffentlichungsdaten wurden, so weit möglich, vom offiziellen FTP-Server übernommen.[17]

Version Datum Bemerkungen
Ältere Version; nicht mehr unterstützt: 1.0 März 1992
Ältere Version; nicht mehr unterstützt: 1.x 1992–1994
Ältere Version; nicht mehr unterstützt: 1.09 November 1994
Ältere Version; noch unterstützt: 2.0 Februar 1997
Ältere Version; noch unterstützt: 2.1 Mai 1999
Ältere Version; noch unterstützt: 2.2 Januar 2001
Ältere Version; noch unterstützt: 2.3 Oktober 2002 Native POSIX Thread Library (NPTL)
Ältere Version; noch unterstützt: 2.4 6. März 2006
Ältere Version; noch unterstützt: 2.5 29. September 2006
Ältere Version; noch unterstützt: 2.6 17. Mai 2007
Ältere Version; noch unterstützt: 2.7 19. Oktober 2007
Ältere Version; noch unterstützt: 2.8 11. April 2008
Ältere Version; noch unterstützt: 2.9 10. März 2009
Ältere Version; noch unterstützt: 2.10 Mai 2009 (?) Datum der Version 2.10.1
Ältere Version; noch unterstützt: 2.11 3. November 2009
Ältere Version; noch unterstützt: 2.12 August 2010 (?) Datum der Version 2.12.1
Aktuelle Version: 2.13 1. Februar 2011 (?)
Aktuelle Version: 2.14 1. Juni 2011
Aktuelle Version: 2.15 21. März 2012
Aktuelle Version: 2.16 30. Juni 2012
Aktuelle Version: 2.17 25. Dezember 2012
Aktuelle Version: 2.18 12. August 2013
Aktuelle Version: 2.19 8. Februar 2014
Aktuelle Version: 2.20 7. September 2014
Aktuelle Version: 2.21 6. Februar 2015
Aktuelle Version: 2.22 5. August 2015
Aktuelle Version: 2.23 19. Februar 2016

Literatur[Bearbeiten | Quelltext bearbeiten]

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. URL der Fundstelle: https://sourceware.org/ml/libc-alpha/2016-02/msg00502.html, Titel: The GNU C Library version 2.23 is now available, Sprache des Werks oder des Namens: Englisch, Veröffentlichungsdatum: 19. Februar 2016, abgerufen am: 20. April 2016
  2. Bug 5070 - glibc-2.5: ../sysdeps/unix/sysv/linux/check_pf.c:68: make_request: Assertion fails
  3. a b Ulrich Drepper: Dictatorship of the Minorities (englisch) udrepper.livejournal.com. 25. Mai 2005. Abgerufen am 15. Januar 2012: „Which architectures are worthwhile supporting? [...]. Not only do we have to look for irrelevance (what percentage cares about Vax, PArisc) support, we also have to look at the level of added complexity the support requires. Some ABIs are just deliberately defined to be different from others (see IA-64) which requires huge amounts of effort to be spent. There are also significantly diverging capabilities (e. g., the lack of atomic operations in too many architectures). This far too often causes to unnecessarily crippled code since writing code in a way which allows optimal use in all situations is very difficult. The solution must be to restrict support to only a handful of architectures which are supported in the project. All other support must happen outside the tree and therefore all the work has to be done by the special interest groups. I don't want to say we follow all these points perfectly, but for a big project glibc certainly comes closest to this.
  4. Linus Torvalds: Posting to the glibc mailing list, 9. Januar 2002 19:02:37
  5. Jonathan Corbet: A turning point for GNU libc. LWN.net. 28. März 2012.: „Of the nearly 19,000 commits found in the project's git repository (which contains changes back to 1995), over 12,000 were made by Ulrich.
  6. glibc homepage.: „In 2001 The GNU C Library Steering Committee ..., was formed and currently consists of Mark Brown, Paul Eggert, Andreas Jaeger, Jakub Jelinek, Roland McGrath and Andreas Schwab.“
  7. Ulrich Drepper: RMS is at it again. sourceware.org. 26. Juni 2000. Abgerufen am 20. November 2015: „A few weeks ago RMS started the next attack on me (a single mail, followed by indirect tries to take influence, followed by another mail today). The essence is that he complains I am not following "GNU policies" and therefore have to be replaced by a steering committee of which I could be a part. Some of you (namely Roland and Andreas S.) probably knowabout this since he proposed both as other members of the committee. In addition there was Mark Brown listed (I know somebody of this name at IBM who would also fit in this group but I'm not sure whether it is really him.) Anyhow, I completely reject this. It is not helping at all, the opposite is true. First, I am not aware of any essential policies I'm violating. The only ones are that I'm not following orders from RMS which clearly have political intends (which is of course a sacrilege) and possibly that I do not care about Winblowz (if the latter counts at all). None of this will change in any way.
  8. Ulrich Drepper: glibc 2.2.4. sourceware.com. 15. August 2001. Abgerufen am 29. November 2015: „And now for some not so nice things. Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC).
  9. rms-accused-of-attempting-glibc-hostile-takeover auf slashdot.com am August 19, 2001
  10. Sourceware-Information zum glibc-Repo
  11. http://www.eglibc.org/home
  12. http://www.eglibc.org/faq
  13. Aurélien Jarno: Debian is switching to EGLIBC (englisch) aurel32.net. 5. Mai 2009. Abgerufen am 15. Januar 2012: „More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers” (as opposed to this).
  14. timothy: Debian Switching From Glibc To Eglibc (englisch) Slashdot. 6. Mai 2009. Abgerufen am 14. Januar 2012.
  15. Debian is switching (back) to GLIBC (englisch) Aurélien. 19. Juni 2014. Abgerufen am 19. Juni 2014.
  16. http://www.eglibc.org/news
  17. http://ftp.gnu.org/gnu/glibc/