I have been using Musl for various purposes for quite some time. I think my favourite things are:
* The team are very helpful, and fix things fast and correctly. You can see some of the detail in this post on race conditions in glibc http://ewontfix.com/16/
* It is very standards compliant, so it is a good portability test for your code. It is a bit like using a BSD libc, except it does have Linux specific syscalls etc.
* Static linking works, which it doesnt properly in glibc. If you want to be like those trendy Go people and provide simple statically linked single file binaries, for running in containers etc then you can. And they will be small: the glibc shared library is 1.8MB (not including rt, pthread etc), while a Musl statically linked copy of Lua for example is only 160k. Static linking is very useful for all sorts of things, my most recent use was cross compiling bianries to run under qemu-user for testing.
* It is BSD licensed so you can use it in completely different projects however you want, eg OSv uses it http://osv.io/
* The code is small and readable. If you want to know how things work you can just take a look, quickly find the code and understand it. Just finding the code in glibc takes ages. I keep a reference copy just for this purpose.
You can use the "cross compiler" musl-gcc that ships with it to build if your code is happy being cross compiled (should be, most things just work). If you have a lot of dependencies it might be easier to use a distro, I use Sabotage in a chroot usually https://github.com/sabotage-linux/sabotage
Not to offend any secondary Musl contributor, but I think that your first favorite thing is all the more impressive that “The team” is essentially one person.
Also, without the work of the entire community testing and reporting issues getting various packages to work with musl, it would have taken forever to get this far. Testers and bug reporters are seriously under-appreciated!
A few big names are in the process of adding musl-based variants or switching entirely to musl, but most of these are still experimental. Alpine hopes to finish switching over sometime this year. Aboriginal Linux too. Bedrock Linux is already using musl in their latest release, but due to the way their distro works, they're in the unique situation where they don't have to build a lot of packages against the system libc, so they have it much easier.
I'm the founder / lead developer of Bedrock Linux, which as dalias said uses musl (as of our latest release). They've been very prompt about fixing any issues we have with musl and making it very hard to find excuses not to use musl.
Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!
The original idea goes back to around 2005 and frustration at the ever-growing size of glibc and poor (slow) support for UTF-8. At the time I made a prototype and used it personally. In 2010 I relaunched the project with a goal of doing it a lot better and targeting user bases who might actually be looking for a new libc; later on this turned out to include a lot of people unhappy with GPL/LGPL, so we re-licensed from LGPLv2.1+ to MIT.
Is there any overview of differences/missing pieces in respect to glibc ? (I'd expect most of them are GNU extensions or or legacy, e.g. at a glance, no SunRPC, fts.h, obstack.h, fstab.h). And how is C11 library support ?
In regards to fts.h, the version in glibc is not even usable because it only works in 32-bit off_t mode, and stat() randomly fails in this mode due to modern inode numbers being 64-bit. See the recent thread on the glibc mailing list: https://sourceware.org/ml/libc-alpha/2014-03/msg00408.html and the bug tracker issue linked.
At this point both musl and glibc only cover a very small portion of C11 additions. glibc has a GSoC project proposal (with 3+ students interested in it) to add C11 threads, which is one of the big missing areas. We've been holding off on doing so in musl in an interest of making sure we do it in a way that's ABI-compatible with glibc, so we'll probably add C11 threads in the near future too.
How much abstraction does musl have over the use of Linux syscalls, and how easily could it supply a partial libc for some other environment, such as an embedded bare-metal environment?
A relatively small number of syscalls are used as part of implementing other functions. Most if not all of these are made via macros that expand to inline syscalls; by replacing them with a call into your own function that implements the equivalent of the syscalls you need "on the metal" rather than calling into a kernel, most of the work is done.
Some syscalls are made directly from assembly source files because C is unable to represent the work that needs to be done around them (e.g. clone and vfork) or simply because their usage is arch-specific. These obviously use the trap-to-kernel instructions directly and cannot be re-routed as described above. Still the number of files is so small you could just rewrite the asm.
One future direction (albeit with lower priority than further functionality/quality improvements, unless somebody funds it) is making it easier to port to bare-metal and documenting the process.
LD_PRELOAD alone wouldn't do it because glibc's dynamic linker is closely tied to glibc. In particular thread-local storage requires close cooperation between them. Likewise, musl needs its own dynamic linker.
What could be done in theory is replacing /lib/ld-linux.so.2 with a symlink to musl. One of the long-term goals for musl is for this to actually work, at least for many programs. But right now there are a lot of glibc-specific symbols that get pulled in magically by glibc's headers, even when the program at the source-level is 100% portable code, and we don't have coverage for all of these.
Excellent response! I have a program that spends 10% of it's time in vfprintf for string processing, and I really think the program should not be spending that much time/any time there. I looked at the libc6 vfprintf implementation and it's pretty esoteric looking stuff. It might be worth my time using your library or something similar to swap it out.
@dalias is very active on the glibc list. Back when he started it was in a dark period and not responsive to change. It is better now, but there is space for something as different as Musl.
At the time the project was started, Ulrich Drepper was the maintainer of glibc and the official response to any bug report was "STFU". So, no.
Aside from that, while a more permissive license was not part of my original goal or vision for musl, it's something that could never have happened by working on improving glibc. Right now we're facing a situation where Linux has been fragmented into a "GNU/Linux" minority made up of hackers' desktop PCs and enterprise servers, and an overwhelming Android majority. The latter is using a grotesquely incompatible, poorly designed, non-standards-conforming libc called Bionic, and if you want to run existing C programs on Android, you have to add heaps of #ifdef hackery to them to make them compatible with Bionic (much like the #ifdef hackery needed to make C programs work on Windows).
musl can provide a real, standards-conforming libc for use on Android that's still light and MIT-licensed (important because Open Handset Alliance members have a contractual obligation to Google not to add copyleft code to the system they distribute). This means, in theory, we can do away with the whole #ifdef mess and just run existing, portable software on Android. In short, it has the potential to free FOSS projects from getting bogged down in the maintenance burden of supporting yet another gratuitously-incompatible system (Android) in order to remain relevant.
I would really like Android to switch over to Musl and drop Bionic, and eventually also drop SurfaceFlinger for Wayland and use an upstream kernel. I can dream...
musl actually has very little in the way of optimization, premature or otherwise. Most functions are written to be as simple and direct as possible. Often but not always this gives near-optimal size and speed too. The places where more complex approaches are used are _mostly_ situations where the naive solution would have corner cases that fail or corner cases that have pathologically bad performance and could be used as a DoS attack vector. The main exception is things like memcpy, memset, etc.; if they're slow, people are generally very unhappy.
BTW, one difficulty in libc is that it's hard to know what optimizations are "premature" because you can't envision everybody's usage cases without an enormous volume of experience with third-party code.
37 comments
[ 5.7 ms ] story [ 88.5 ms ] thread* The team are very helpful, and fix things fast and correctly. You can see some of the detail in this post on race conditions in glibc http://ewontfix.com/16/
* It is very standards compliant, so it is a good portability test for your code. It is a bit like using a BSD libc, except it does have Linux specific syscalls etc.
* Static linking works, which it doesnt properly in glibc. If you want to be like those trendy Go people and provide simple statically linked single file binaries, for running in containers etc then you can. And they will be small: the glibc shared library is 1.8MB (not including rt, pthread etc), while a Musl statically linked copy of Lua for example is only 160k. Static linking is very useful for all sorts of things, my most recent use was cross compiling bianries to run under qemu-user for testing.
* It is BSD licensed so you can use it in completely different projects however you want, eg OSv uses it http://osv.io/
* The code is small and readable. If you want to know how things work you can just take a look, quickly find the code and understand it. Just finding the code in glibc takes ages. I keep a reference copy just for this purpose.
You can use the "cross compiler" musl-gcc that ships with it to build if your code is happy being cross compiled (should be, most things just work). If you have a lot of dependencies it might be easier to use a distro, I use Sabotage in a chroot usually https://github.com/sabotage-linux/sabotage
Also, without the work of the entire community testing and reporting issues getting various packages to work with musl, it would have taken forever to get this far. Testers and bug reporters are seriously under-appreciated!
False. It doesn't. At the very least, VDSO support on Linux for static builds is broken.
I.e., calls to time() and gettimeofday() and friends will be orders of magnitude slower when linking statically.
Looking at the code I think nobody on the team was even aware that this is an important corner case.
I'll stick to glibc, they at least do proper testing.
A few big names are in the process of adding musl-based variants or switching entirely to musl, but most of these are still experimental. Alpine hopes to finish switching over sometime this year. Aboriginal Linux too. Bedrock Linux is already using musl in their latest release, but due to the way their distro works, they're in the unique situation where they don't have to build a lot of packages against the system libc, so they have it much easier.
(even though the 2 links are completely different)
In regards to fts.h, the version in glibc is not even usable because it only works in 32-bit off_t mode, and stat() randomly fails in this mode due to modern inode numbers being 64-bit. See the recent thread on the glibc mailing list: https://sourceware.org/ml/libc-alpha/2014-03/msg00408.html and the bug tracker issue linked.
At this point both musl and glibc only cover a very small portion of C11 additions. glibc has a GSoC project proposal (with 3+ students interested in it) to add C11 threads, which is one of the big missing areas. We've been holding off on doing so in musl in an interest of making sure we do it in a way that's ABI-compatible with glibc, so we'll probably add C11 threads in the near future too.
A relatively small number of syscalls are used as part of implementing other functions. Most if not all of these are made via macros that expand to inline syscalls; by replacing them with a call into your own function that implements the equivalent of the syscalls you need "on the metal" rather than calling into a kernel, most of the work is done.
Some syscalls are made directly from assembly source files because C is unable to represent the work that needs to be done around them (e.g. clone and vfork) or simply because their usage is arch-specific. These obviously use the trap-to-kernel instructions directly and cannot be re-routed as described above. Still the number of files is so small you could just rewrite the asm.
One future direction (albeit with lower priority than further functionality/quality improvements, unless somebody funds it) is making it easier to port to bare-metal and documenting the process.
What could be done in theory is replacing /lib/ld-linux.so.2 with a symlink to musl. One of the long-term goals for musl is for this to actually work, at least for many programs. But right now there are a lot of glibc-specific symbols that get pulled in magically by glibc's headers, even when the program at the source-level is 100% portable code, and we don't have coverage for all of these.
Aside from that, while a more permissive license was not part of my original goal or vision for musl, it's something that could never have happened by working on improving glibc. Right now we're facing a situation where Linux has been fragmented into a "GNU/Linux" minority made up of hackers' desktop PCs and enterprise servers, and an overwhelming Android majority. The latter is using a grotesquely incompatible, poorly designed, non-standards-conforming libc called Bionic, and if you want to run existing C programs on Android, you have to add heaps of #ifdef hackery to them to make them compatible with Bionic (much like the #ifdef hackery needed to make C programs work on Windows).
musl can provide a real, standards-conforming libc for use on Android that's still light and MIT-licensed (important because Open Handset Alliance members have a contractual obligation to Google not to add copyleft code to the system they distribute). This means, in theory, we can do away with the whole #ifdef mess and just run existing, portable software on Android. In short, it has the potential to free FOSS projects from getting bogged down in the maintenance burden of supporting yet another gratuitously-incompatible system (Android) in order to remain relevant.
BTW, one difficulty in libc is that it's hard to know what optimizations are "premature" because you can't envision everybody's usage cases without an enormous volume of experience with third-party code.