libc
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 package 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/23.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 stage 3 stage files 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 stage 3s and profiles, please review the Gentoo Handbook.
See also
- Gentoo Toolchain Project, responsible of managing the GNU libc package
- Gentoo Hardened musl Project
- Gentoo Hardened uClibc Project