Libc

For Unix-like operating systems, the libc is Article description::a software component that allows userspace applications to interact with operating system services. It 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 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:
 * , 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.
 * , 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.
 * , (No longer supported, please use musl) 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.

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 ) have package  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 ) set ELIBC to, which causes virtual/libc to be satisfied by sys-libs/musl. uClibc-ng-based profiles (those with 'uclibc' in the name, like ) set ELIBC to, which causes virtual/libc to be satisfied by sys-libs/uclibc-ng. Otherwise, ELIBC is set to, 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 directory instead of the standard  directory. Their names have the forms and. 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.

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