libc

From Gentoo Wiki
Jump to: navigation, search

Resources

The libc is a software component that allows userspace applications to interact with operating system services. For Unix-like operating systems, it is an implementation of the facilities specified by the library clause of the C programming language standard, ISO/IEC International Standard 9899, of the POSIX (Portable Operating System Interface) and X/Open system interfaces as defined in IEEE Standard 1003.1, and of other extensions. On Linux distributions this implementation normally takes the form of one or more Executable and Linking Format (ELF) shared object files ('.so files'), with architecture-specific machine code that processes load at runtime using dynamic linking. Dynamic linking makes the libc a runtime dependency of pretty much every package, and thus a core component of the distribution.

Gentoo's libc setup

Gentoo supports three libc implementations for Linux:

  • sys-libs/glibc, from the GNU project, one of the oldest, best-known free software libc implementations. The GNU-style target triplets that represent the resulting operating system (for using e.g. as values of CHOST) have the form *-*-linux-gnu*.
  • sys-libs/musl, from the musl project, aimed at being simple, lightweight, fast and correct in the sense of standards-conformance and safety. The GNU-style target triplets that represent the resulting operating system have the form *-*-linux-musl*.
  • sys-libs/uclibc-ng, from the uClibc-ng project, a small libc implementation aimed at developing embedded Linux systems. The GNU-style target triplets that represent the resulting operating system have the form *-*-linux-uclibc*.

The choice of libc implementation for a Gentoo machine is governed by profiles. Profiles that select the Linux kernel (KERNEL USE_EXPAND variable set to linux) have package virtual/libc in the system set, i.e. it is guaranteed to be present in every Gentoo machine. This is a virtual package, that is, it installs no files but has an any-of dependency, || ( ... ), on other packages, or a similar construct. For these profiles, virtual/libc can be satisfied by one of the aforementioned libc packages depending on the value of the ELIBC USE_EXPAND variable. Musl-based profiles (those with 'musl' in the name, like default/linux/amd64/17.0/musl) set ELIBC to musl, which causes virtual/libc to be satisfied by sys-libs/musl. uClibc-ng-based profiles (those with 'uclibc' in the name, like default/linux/arm/17.0/uclibc) set ELIBC to uclibc, which causes virtual/libc to be satisfied by sys-libs/uclibc-ng. Otherwise, ELIBC is set to glibc, which causes virtual/libc to be satisfied by sys-libs/glibc.

ELIBC, just like KERNEL, can only be set by profiles.

Musl and uClibc-ng stage3 tarballs are available in Gentoo mirrors, in 'vanilla' and hardened variants, although some of them, depending on architecture, might be found in the /experimental directory instead of the standard /releases/*/autobuilds/current-stage3-* directory. Their names have the forms stage3-*-musl-{vanilla,hardened}-*.tar.{bz2,xz} and stage3-*-uclibc-{vanilla,hardened}-*.tar.{bz2,xz}. There is also an official musl ebuild repository, available with eselect repository or Layman under the name "musl", which houses additional patches that allow several packages to build with sys-libs/musl.

Important
Musl-based and uClibc-ng-based profiles are currently labeled 'experimental', i.e. eselect profile list would show "(exp)" after the profile name. Most stable Linux profiles are currently GNU libc-based only.

For a refresher on stage3 tarballs and profiles, please review the Gentoo Handbook.

See also