musl, pronounced like the word “mussel” or “muscle”, is a “libc”, animplementation of the standard library functionality described in theISO C and POSIX standards, plus common extensions, built on top of theLinux system calls API. While the kernel governs access to hardware,memory, filesystems, and the privileges for accessing these resources,libc is responsible for:
providing C bindings for the OS interfaces
constructing higher-level buffered stdio, memory allocationmanagement, thread creation and synchronization operations, sharedlibrary loading, and so on using the lower-level interfaces thekernel provides
implementing the pure library routines of the C language likestrstr,snprintf,strtol,exp,sqrt, etc.
musl has history and development roots going back to 2005, but wasnamed and first released as musl in 2011, as an alternative to glibcand uClibc with an ambitious goal to meet the needs of both tinyembedded systems and typical desktops and servers.
Since 2012, musl has been licensed under the permissiveMITlicense.
The simpler code is, the less room it has for bugs, and the lesscostly it is to make major changes when they're required. Simplicitytends to lead naturally to optimal code size and reasonably-goodperformance. musl favors simple algorithms over more complex onesunless there's a compelling reason to do otherwise. musl also favorsminimizing abstractions, keeping code as self-contained/uncoupled aspossible. This tends to make itreadable (although sometimesdense) and size-efficient when static-linked.
Scaling well "asn goes to 0" can matter as much if not more thanscaling "asn goes to ∞". Design around this principle started outwith embedded and low-end desktops in mind, but ended up carrying musl(and like-minded distributions) to prominence in the containerdeployment wave.
Due to lack of heavy internal coupling between libc components, staticlinking with musl pulls in very little code that the application isn'tactually using. Minimal static-linked binaries can be under 10 kB ofcode, even with threads, and even useful programs can be under 50 kB.
The principle of low constant overhead applies to runtime resourceconsumption as well. libc's own global data size is kept as small aspossible - under 8k, and potentially much less when static linking.For dynamic linking, all functionality is in a single shared libraryfile (rather than being split acrosslibm,libpthread,librt,etc.) so that there's no per-component memory and startup timeoverhead.
Part of musl's scaling "asn goes to 0" is the ability to run onsmall stacks, making designs involving large numbers of threadspractical even in resource-constrained environments.
musl was the first Linux libc to have mutexes safe to use insidereference-counted objects, the first to have condvars wherenewly-arrived waiters can't steal wake events from previous waiters,and the first to have working thread cancellation without raceconditions producing resource-leak or double-close. All of these arerequirements of the specification that were ignored by otherimplementations, and getting them right was a consequence ofcarefulreading of those specifications.
musl's entire development history has been a process of readingspecifications, seeking clarifications when corner cases aren'tadequately covered, and proceeding with extreme caution whenimplementing functionality that's underspecified.
Part of correctness is not getting yourself into a bad situation withno way out. musl always reserves resources for an operation beforecommitting to it, backing out if resources are not available.Low-memory or other resource exhaustion conditions are never fatal;they're always caught (assuming a no-overcommit system configuration)at a point where they can be reported, allowing the application tohandle them as it deems fit.
In general, musl avoids unnecessary dynamic allocation, and has nodynamic allocation at all in code paths where reporting failure to thecaller is not a possibility.
musl's MIT license is compatible with all FOSS licenses,static-linking-friendly, and makes commercial use painless. Binariesstatically linked with musl have no external dependencies, even forfeatures like DNS lookups or character set conversions that areimplemented with dynamic loading on glibc. An application can reallybedeployed as a single binary file and run on any machine withthe appropriate instruction set architecture and Linux kernel or Linuxsyscall ABI emulation layer.
From even before musl was musl, treatment of all text as UTF-8, andtreatment of non-ASCII characters as first-class, was a corerequirement. No external locale files or conversion modules are neededto process UTF-8 or query properties of arbitrary Unicode characters.Even musl'sgetopt allows arbitrary Unicode characters to be used asoptions.
DNS support for non-ASCII domains (IDN) is not complete yet but willbe supported in the future.
Localization functionality, a related but different matter, is alsopresently limited but slated for major improvements.
With themusl-gcc (ormusl-clang) wrapper shipped with muslsource, it's possible on x86 Linux and other mainstream archs toevaluate musl and build simple C programs by repurposing your system'sexisting glibc-based toolchain. For more advanced usage involvinglibraries or C++, though, a dedicated cross toolchain or building in amusl-based distribution is recommended. Details can be found on thecommunity wiki'sGettingStarted page.