Jump to content

Glibc

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Alexey Izbyshev (talk | contribs) at 20:55, 16 November 2016 (→History: Fix name of 64-bit ARM architecture). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"glibc" redirects here. Not to be confused with GLib or Gnulib.

GNU C Library
Original author(s)Roland McGrath
Developer(s)GNU Project
Initial release1987; 37 years ago (1987)[1]
Repository
Written inC
Operating systemUnix-like
TypeRuntime library
LicenseGNU Lesser General Public License
Websitewww.gnu.org/software/libc/
The Linux API is composed out of the System Call Interface of the Linux kernel, the GNU C Library (by GNU), libdrm, libalsa and libevdev (by freedesktop.org).
The GNU C Library is a wrapper around the system calls of the Linux kernel.
The Linux kernel and GNU C Library together form the Linux API. After compilation, the binaries offer an ABI.

The GNU C Library, commonly known as glibc, is the GNU Project's implementation of the C standard library. Despite its name, it now also directly supports C++ (and, indirectly, other programming languages). It was started in the early 1990s by the Free Software Foundation (FSF) for their GNU operating system.

Released under the GNU Lesser General Public License, glibc is free software.

History

The Glibc project was initially written mostly by Roland McGrath, working for the Free Software Foundation (FSF) in the 1980s.

In February 1988, FSF described glibc as having nearly completed the functionality required by ANSI C.[2] By 1992, it had the ANSI C-1989 and POSIX.1-1990 functions implemented and work was under way on POSIX.2.[3]

Fork "Linux libc"

In the early 1990s, the developers of the Linux kernel forked glibc. Their fork, called "Linux libc", was maintained separately for years and released versions 2 through 5.

When FSF released glibc 2.0 in January 1997, it had much more complete POSIX standards compliance, better internationalisation and multilingual function, IPv6 capability, 64-bit data access, facilities for multithreaded applications, future version compatibility, and the code was more portable.[4] At this point, the Linux kernel developers discontinued their fork and returned to using FSF's glibc.[5]

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[6] (Alpha and IA64 architectures now use libc.so.6.1, instead). The *.so file name is often abbreviated as libc6 (for example in the package name in Debian) following the normal conventions for libraries.

According to Richard Stallman, the changes that had been made in Linux libc could not be merged back into glibc because the authorship status of that code was unclear and the GNU project is quite strict about recording copyright and authors.[7]

Installation of a steering committee

Starting in 2001 the library's development had been overseen by a committee,[8] with Ulrich Drepper[9] 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 failed hostile takeover maneuver by RMS.[10][11][12]

Migrated to Git, a distributed VCS

While previously in a CVS repository, in 2009 glibc was migrated to a Git (a distributed version control system) repository on Sourceware.[13]

Debian switches to EGLIBC and back

After long standing controversies around Drepper's leading style and external contribution acceptance,[14][15][16] Debian switched publicly to the glibc fork EGLIBC in 2009,[17] and back with the Debian 8.0 (Jessie) in April 2015.[18]

Steering committee disbands

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).[19][20]

After the change in glibc maintainership Debian and other projects migrated back to the glibc, who before switched to alternatives.[21] Also, since the beginning of 2014, the glibc fork EGLIBC is no longer being developed, since its "goals are now being addressed directly in GLIBC".

Version history

For most systems, the version of glibc can be obtained by executing the lib file (for example, /lib/libc.so.6).

Functionality

glibc provides the functionality required by the Single UNIX Specification, POSIX (1c, 1d, and 1j) and some of the functionality required by ISO C11, ISO C99, Berkeley Unix (BSD) interfaces, the System V Interface Definition (SVID) and the X/Open Portability Guide (XPG), Issue 4.2, with all extensions common to XSI (X/Open System Interface) compliant systems along with all X/Open UNIX extensions.

In addition, glibc also provides extensions that have been deemed useful or necessary while developing GNU.

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[22] includes: 32-bit ARM and its newer 64-bit ISA (AArch64), DEC Alpha, PA-RISC, IA-64, Motorola m68k, MicroBlaze, MIPS, Nios II, PowerPC, s390, SPARC, TILE, and x86. 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.[23] It is also used (in an edited form) and named libroot.so in BeOS and Haiku.[24]

Use in small devices

glibc has been criticized as being "bloated" and slower than other libraries in the past, e.g. by Linus Torvalds[25] 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[26] and Familiar Linux for iPaq handhelds (when using the GPE display software).[27]

Compatibility layers

There are compatibility layers ("shims") to allow programs written for other ecosystems, e.g. Google's Android and Microsoft's Windows, to run on glibc interface offering systems. libhybris is a compatibility layer for Android's Bionic and Wine can be also seen as compatibility layer from Win32 API/ABI to glibc.

See also

References

  1. ^ Corbet, Jonathan (28 March 2012). "A turning point for GNU libc". LWN.net.
  2. ^ "GNU's Bulletin, vol. 1 no. 4, February, 1988". Most libraries are done. Roland McGrath […] has a nearly complete set of ANSI C library functions. We hope they will be ready some time this spring.
  3. ^ "GNU's Bulletin, vol. 1 no. 12". It now contains all of the ANSI C-1989 and POSIX.1-1990 functions, and work is in progress on POSIX.2 and Unix functions (BSD and System V)
  4. ^ Lee, Elliot (2001). "A Technical Comparison of glibc 2.x With Legacy System Libraries". Archived from the original on 11 April 2004.
  5. ^ "Forking: it could even happen to you". the split between GNU LIBC and the Linux LIBC -- it went on for years while Linux stabilized, and then the forks re-merged into one project
  6. ^ "Fear of Forking essay, see "6. glibc --> Linux libc --> glibc"".
  7. ^ "Fear of Forking, footnote on Stallman's merge comments".
  8. ^ "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.
  9. ^ "Ulrich Drepper". LinkedIn. Retrieved 13 June 2012.
  10. ^ Drepper, Ulrich (26 June 2000). "RMS is at it again". sourceware.org. Retrieved 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 know about 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.
  11. ^ Drepper, Ulrich (15 August 2001). "glibc 2.2.4". sourceware.com. Retrieved 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).
  12. ^ rms-accused-of-attempting-glibc-hostile-takeover on slashdot.com on August 19, 2001
  13. ^ glibc repo on Sourceware.com
  14. ^ Ulrich Drepper 2007-10-03 06:13:55 UTC "This has nothing to do with "x86 only". All ABIs designed by people who have a bit of understanding require no change. Any change will negatively impact well designed architectures for the sole benefit of this embedded crap. But your own version of the file in the add-on."
  15. ^ Drepper, Ulrich (25 May 2005). "Dictatorship of the Minorities". udrepper.livejournal.com. Retrieved 15 January 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.
  16. ^ Jarno, Aurélien (5 May 2009). "Debian is switching to EGLIBC". aurel32.net. Retrieved 15 January 2012. More friendly upstream (especially with regard to embedded architectures): "Encourage cooperation, communication, civility, and respect among developers" (as opposed to this).
  17. ^ timothy (6 May 2009). "Debian Switching From Glibc To Eglibc". Slashdot. Retrieved 14 January 2012.
  18. ^ Debian package changelog
  19. ^ McGrath, Roland (26 March 2012). "glibc steering committee dissolving". Sourceware.org. Retrieved 13 June 2012.
  20. ^ Myers, Joseph S. (26 March 2012). "GNU C Library development and maintainers". Sourceware.org. Retrieved 13 June 2012.
  21. ^ "Debian is switching (back) to GLIBC". Aurélien. 19 June 2014. Retrieved 19 June 2014.
  22. ^ "The GNU C Library machine maintainers".
  23. ^ Bartley, David; Spang, Michael. "GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel)". Retrieved 16 December 2008.
  24. ^ "Haiku Source". libroot.so is not part of GNU project and is included in Haiku source code.
  25. ^ Torvalds, Linus (9 January 2002). "Posting to the glibc mailing list".
  26. ^ "OpenMoko components". We will use glibc (not uClibC) … The alternatives may save more space and be more optimized, but are more likely to give us integration headaches
  27. ^ "Re: [Familiar] Which glibc for Familiar 0.8.4  ?". Question: which version of the GLIBC was used to build the Familiar 0.8.4 ? Answer: 2.3.3
Wikimedia Commons has media related to GNU C Library.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Glibc&oldid=749913851"