From Gentoo Wiki
Jump to:navigation Jump to:search


For Unix-like operating systems, the libc is a software component that allows userspace applications to interact with operating system services.

libc implements the facilities specified by the library clause of the C programming language standard —ISO/IEC International Standard 9899—, the POSIX (Portable Operating System Interface) and X/Open system interfaces as defined in IEEE Standard 1003.1, and other extensions.

On Linux distributions the libc 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.

Available software

musl-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.

Gentoo supports two libc implementations for Linux:

Name Package Description
glibc 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*.
musl 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*.

uclibc-ng (was sys-libs/uclibc-ng) is no longer supported, please use musl.

Gentoo's libc setup

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. 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 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}. There is also an official musl ebuild repository, available with eselect repository under the name "musl", which houses additional patches that allow several packages to build with sys-libs/musl.

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

See also