musl versus glibc on Alpine: why some prebuilt binaries, Python wheels and DNS behaviour differ

What it is

Alpine Linux uses musl as its C library instead of glibc. musl is an independent implementation of the C standard library, and its documented functional differences from glibc are not edge cases — they show up routinely when running software built or packaged with glibc assumptions. Three matter most for an agent choosing or operating an Alpine base image: dynamic linking is not binary-compatible (a binary linked against glibc's dynamic linker will not run under musl without a compatibility shim), the DNS resolver behaves differently, and locale support is minimal.

Why it matters

• Prebuilt binaries and wheels: a binary compiled against glibc expects glibc's dynamic linker and symbol versions; running it directly on Alpine fails. Python's manylinux wheel tags assume glibc, so pip on musl does not select them, which is why many packages need a source build (needing a C toolchain and apk add --no-cache matching -dev packages) or a musllinux wheel instead on Alpine.
• DNS resolver differences: musl's resolver "queries them all in parallel and accepts whichever" nameserver responds first, instead of glibc's sequential retry, and — to avoid inconsistent results from a partial failure — musl deliberately skips falling back from a qualified lookup to a search-domain lookup once a query already has enough dots ("never falling back to search, which glibc would do"). musl also uses at most three nameservers, cannot send the A and AAAA queries sequentially (no equivalent of glibc's single-request options), and supports DNS over TCP for large responses only from musl 1.2.4 (Alpine 3.18 and later). Software relying on glibc's resolv.conf behaviour can behave differently on Alpine.
• Locale limits: musl "provides a special C locale" and, unlike glibc's plain "C" default, musl "on the other hand always uses" "C.UTF-8" as its default locale; it does not ship the large locale-data tables glibc does, so software expecting a specific installed locale (rather than UTF-8-clean C behaviour) may not find it.
• Dynamic loading: musl's dynamic loader keeps every loaded library for the life of the process (dlclose is a no-op) and does not support glibc's lazy symbol binding, which changes observable behaviour for plugin-style software that expects reference-counted unloading.

How to apply

• Before adopting Alpine as a base image, check whether required dependencies ship musl-compatible binaries or musllinux/source-installable packages; do not assume a glibc-only vendor binary will run.
• For a handful of unmodified glibc binaries that must run as-is, install gcompat, described in its own documentation as providing "glibc-compatible APIs for use on musl libc systems" via a loader-stub trick — but note the same documentation that it "does not contain any headers, and cannot be used to build" software that itself requires glibc to compile.
• Test DNS-dependent code against Alpine specifically rather than assuming glibc-derived test results transfer, given the parallel-query and no-search-fallback resolver behaviour.
• Where a full locale (not just UTF-8) is genuinely required, treat that as a reason to choose a glibc-based image instead of adding workarounds.

Pitfalls

• Debugging a "binary not found" error as a PATH problem when it is actually the ELF interpreter (glibc's dynamic linker) being absent.
• Assuming gcompat makes Alpine a drop-in glibc replacement for building software, rather than only for running certain already-built binaries.