如果你是一个 Linux 用户，那你一定至少听说过 Glibc 的鼎鼎大名，或者甚至在日常使用中碰到不少关于它的问题，例如 Glibc 版本不匹配等问题。而本文的主角—— Musl libc 与之相比就要默默无闻的多，毕竟绝大多数的 Linux 发行版使用的 libc 库都是 Glibc，只有 Alpine Linux 等极少数 Linux 发行版才会使用 Musl libc，并且还会遇到诸如闭源 JDK 无法正常使用等问题的困扰，那么，为什么我们会需要另一个 libc 函数库呢？
Glibc 并不完美
Glibc 作为目前使用最广泛的 libc 函数库，虽然拥有最广泛的发行版支持和用户群体，并且在兼容性和性能方面也存在一些优势，但它并不完美，有三个问题严重困扰着它。
代码库陈旧
Glibc 拥有悠久的历史——对于软件而言这可能并不一定是一句赞誉，尤其是当你需要处理上世纪九十年代就存在的代码库时。三十多年来，程序员们编写 C 程序的方式并不是一成不变的，某些在那个年代被认为是好习惯或者是必须的编程方式在今天看来可能完全不合时宜，诸如叠床架屋的宏等等。这些问题严重拖累了 Glibc 的源码可读性，例如下面这一段源代码，摘自 Glibc 的 fopen 函数。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
FILE * __fopen_internal (const char *filename, const char *mode, int is32) { struct locked_FILE { struct _IO_FILE_plus fp; #ifdef _IO_MTSAFE_IO _IO_lock_t lock; #endif struct _IO_wide_data wd; } *new_f = (struct locked_FILE *) malloc (sizeof (struct locked_FILE)); if (new_f == NULL) return NULL; #ifdef _IO_MTSAFE_IO new_f->fp.file._lock = &new_f->lock; #endif _IO_no_init (&new_f->fp.file, 0, 0, &new_f->wd, &_IO_wfile_jumps); _IO_JUMPS (&new_f->fp) = &_IO_file_jumps; _IO_new_file_init_internal (&new_f->fp); if (_IO_file_fopen ((FILE *) new_f, filename, mode, is32) != NULL) return __fopen_maybe_mmap (&new_f->fp.file); _IO_un_link (&new_f->fp); free (new_f); return NULL; } |
作为对比，下面是 Musl 库中同样对 fopen 函数的实现
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
FILE *fopen(const char *restrict filename, const char *restrict mode) { FILE *f; int fd; int flags; /* Check for valid initial mode character */ if (!strchr("rwa", *mode)) { errno = EINVAL; return 0; } /* Compute the flags to pass to open() */ flags = __fmodeflags(mode); fd = sys_open(filename, flags, 0666); if (fd < 0) return 0; if (flags & O_CLOEXEC) __syscall(SYS_fcntl, fd, F_SETFD, FD_CLOEXEC); f = __fdopen(fd, mode); if (f) return f; __syscall(SYS_close, fd); return 0; } |
两者的可读性差距不言自明，笔者在这里并非是要批判 Glibc 的代码风格，但对于初次上手阅读源码的人来说，显然是 Musl 的风格更加友好，更便于理解。
体积过大
由于 Glibc 相较体积更加关注性能，因此其链接生成的二进制文件相较于 Musl uClibc 等专注于嵌入式等场合的库来说要大很多，而这些场合往往非常关注几百 K 大小的区别，因为 SRAM 的大小往往关乎整体开发板的成本。
下面这张表展示了不同 libc 库编译的文件大小。
| 尺寸对比 | musl | uClibc | dietlibc | glibc |
|---|---|---|---|---|
| .a | 426k | 500k | 120k | 2.0M |
| .so | 527k | 560k | 185k | 7.9M |
| 静态最小 | 1.8k | 5k | 0.2k | 662k |
| 静态输出 | 13k | 70k | 6k | 662k |
可以看出 Glibc 在程序大小上明显大于其他 libc 库，此外，这里的静态也是有水分的，这就引出了 Glibc 的下一个问题，也是最重要的问题之一：静态链接。
对静态链接支持不佳
理论上来说，Glibc 是支持静态链接的。但，这也仅仅是从理论上来说，由于一些历史遗留问题（当然，也包括对功能实现的考虑）Glibc 的静态链接并不是真正的静态链接：如果你的程序中使用了某些不支持静态链接的特性（这一点在大型软件中非常常见），那么即便你在链接时选择静态链接，生成出来的程序实际上仍然是依赖于 Glibc 动态库的，一旦你尝试删除掉它，你立马就会发现这些“静态”链接的程序统统罢工不干了。
谁在用 Musl？
在发行版中，主要是 Alpine Linux，作为最特立独行的 Linux 发行版之一，它选用了 Musl + Busybox 的组合，而非通常的 Glibc + Coreutils，这使得它的最小安装可以控制在惊人的 5 MB 之内！相比之下，普通的 CentOS 最小安装则需要 200 MB 左右，这一点使得它在嵌入式等对内存占用极为敏感的场合占据了相当的优势。
此外，Musl 从设计之初就很关注静态链接的可用性，因此它完全可以被静态链接进其他程序中，不存在 Glibc 对动态库的依赖问题，这一点也有助于缓解不同版本 libc 之间的兼容性问题——只要我把万物都静态链接进去，就不存在版本问题了。当然，这种做法也会带来体积膨胀等问题，所以并不是一个太好的解决方案。
Musl 的问题与未来
虽然拥有诸多优点，但 Musl 在性能方面逊于 Glibc 也是不争的事实，毕竟简化实现的代价就包括牺牲性能，不过这一点并非不可拯救，通过使用开源的 malloc 实现（诸如微软的实现）替换这些对性能影响较大的热点函数，就可以在很大程度上解决性能方面的问题。
同时，试图取代或至少部分取代 Glibc 的库也并不止 Musl 一个， 例如用于 AOSP 项目上的 bionic，以及广泛应用于各种嵌入式开发中的 uClibc 等。与它们相比，Musl 背后既没有 Google 这样的大公司撑腰，在压缩体积方面做的也不够极致，相较之下就没有那么受到开发者们的青睐，在新功能和新特性跟进上也不是非常积极。
出于这些原因，也许 Musl 在今后的很长一段时间内会继续保持这种“小而美”的特点，但这对于我们来说并非就是一件坏事，能够看到与 GNU Glibc 风格截然不同的另一种实现，对于 Linux 社区的多样性，以及对于我们这些学习者来说，何尝不是一件美事？