Install glibc with Homebrew, dnf, Nix, pacman, zypper, apt

Project links

• Homepage

Commands and aliases

• gencat
• getconf
• getent
• iconvconfig
• ld.so
• ldconfig
• ldd
• locale
• localedef
• makedb
• mtrace
• nscd
• pcprofiledump
• pldd
• sln
• sotruss
• sprof
• tzselect
• xtrace
• zdump
• zic

Project history

The GNU C Library belongs to the GNU project's effort to provide a complete free Unix-like system. GNU FTP archives show glibc 1.09-era tarballs in the mid-1990s and glibc 2.0.1 in 1997, after which the 2.x line became the long-lived ABI base for Linux distributions.

Sourceware's glibc wiki describes the library as the C library for GNU systems and most Linux-kernel systems, with goals of portability, performance, standards conformance, and extensive internationalization. Its interface history is shaped by ISO C, POSIX, BSD, System V, GNU extensions, and compatibility modes selected at application build time.

glibc development is organized around the Sourceware Git repository, Bugzilla, architecture maintainers, libc-alpha review, release management, and a large testsuite. The project has to balance new CPU architectures, compiler behavior, Linux kernel interfaces, POSIX standards, security fixes, and backwards-compatible ABI promises.

Adoption history

glibc became one of the defining packages of mainstream Linux distributions because nearly every dynamically linked C program depends on the loader and libc ABI. Distribution upgrades, container base images, cross-toolchains, and binary compatibility policies all treat glibc as a core system component rather than an ordinary leaf package.

Its adoption also made it a reference point for alternatives such as musl, uClibc-ng, Bionic, and BSD libcs. Those projects are often evaluated against glibc's breadth, compatibility, locale behavior, dynamic linker features, and Linux ecosystem expectations.

How it is used

Practitioners rarely call glibc as a standalone application; they compile and link C, C++, Go cgo, Rust libc-using crates, Python extensions, and many other native programs against its headers and shared libraries. Runtime tools such as `ldd`, `getconf`, `getent`, `locale`, `localedef`, `iconv`, and `ldconfig` expose pieces of that system layer to administrators and packagers.

Toolchain and packaging work often involves matching glibc with GCC or clang, binutils, Linux kernel headers, and distribution policy. Developers use the manual for APIs, feature-test macros, portability notes, locale behavior, memory allocation, dynamic loading, threads, sockets, name service, and process facilities.

Why package nerds care

glibc is one of the packages that defines a Linux system's ABI. A version bump can affect symbol versions, dynamic loader behavior, DNS and NSS behavior, locale archives, threading primitives, container compatibility, and the minimum runtime expected by prebuilt binaries.

For package managers, glibc is therefore both dependency and platform. It must be upgraded with care, tested broadly, and kept compatible with binaries built over many years, while still tracking kernel, compiler, security, and standards changes.

Timeline

• 1994: GNU FTP archive lists glibc 1.09 crypt add-on material.
• 1997: glibc 2.0.1 archive published.
• 2000s: glibc 2.x became the common C library base for major Linux distributions.
• 2010s: Sourceware Git, Bugzilla, architecture maintainers, and libc-alpha review became the visible development workflow.
• 2020s: Twice-yearly release management and broad CI/testsuite work continued around Linux, GNU, compiler, and CPU-architecture changes.

Related projects

• glibc is tied to the GNU Compiler Collection, binutils, Linux kernel headers, GNU Hurd, POSIX standards work, Linux man-pages, distribution toolchains, musl, uClibc-ng, Bionic, and BSD C libraries.

Sources

• https://ftp.gnu.org/gnu/glibc/
• https://sourceware.org/glibc/manual/2.43/html_node/Introduction.html
• https://sourceware.org/glibc/wiki/HomePage
• https://www.gnu.org/software/libc/