GNU C Library Alternative Musl Libc Hits 1.0 Milestone

New submitter dalias (1978986) writes "The musl libc project has released version 1.0, the result of three years of development and testing. Musl is a lightweight, fast, simple, MIT-licensed, correctness-oriented alternative to the GNU C library (glibc), uClibc, or Android's Bionic. At this point musl provides all mandatory C99 and POSIX interfaces (plus a lot of widely-used extensions), and well over 5000 packages are known to build successfully against musl.

Several options are available for trying musl. Compiler toolchains are available from the musl-cross project, and several new musl-based Linux distributions are already available (Sabotage and Snowflake, among others). Some well-established distributions including OpenWRT and Gentoo are in the process of adding musl-based variants, and others (Aboriginal, Alpine, Bedrock, Dragora) are adopting musl as their default libc." The What's New file contains release notes (you have to scroll to the bottom). There's also a handy chart comparing muscl to other libc implementations: it looks like musl is a better bet than dietlibc and uclibc for embedded use.

Either gnu libc is hideously slow and bloated...

[Viol8]

... which I don't believe because the guys at gnu know a thing or 2 about compilers and libraries - or this library has cut some corners and/or missed out some functionality.

Re:Either gnu libc is hideously slow and bloated..

[staalmannen]

It might be easier to add than to remove, leading to bloat over time and glibc has been around for a while. Also, building on old code might mean that you are limited in what you can change. For example, the modular design of LLVM has been a pretty big success and is considered easier to work with/develop than gcc. For musl, I think they have decided to remove all legacy stuff + non-standard extensions.

Re:Either gnu libc is hideously slow and bloated..

[Improv]

Steps to a useless comment:
1) Speculate on the features of something
2) Note that that speculated feature set doesn't include something you want
3) Criticise based on your speculation

Re:

[account_deleted]

Comment removed based on user account deletion

Musl's supported architectures

[uhmmmm]

You're right that musl doesn't support the same breadth of architectures that glibc does. They currently support x86, amd64, ARM, MIPS, PPC, microblaze, and they have experimental support for superh and x32.

One big advantage they do have is that it's much simpler to add support for a new architecture to musl than it is to add it to glibc. They are interested in supporting more architectures, so I'd expect their list of supported architectures to grow fairly quickly if there are people interested in that support.

Re:Musl's supported architectures

[dalias]

We have people working on aarch64, someone interested in doing a sparc port, and interest from the OpenRISC folks in musl too (and I've offered to help them with a port). There's also someone who wants to port to LM32-mmu (which, as I understand it, doesn't have any userspace infrastructure yet and only a very experimental kernel port).

Re:

[uhmmmm]

What is involved in a port?

This list is probably not absolutely 100% complete, but it should be pretty close:

• A number of header files defining system call numbers, and structures for interfacing with the kernel. Musl does not require or use the linux kernel headers, so these definitions must be provided by the port itself.
• Assembly code for making system calls. There's an inline function version, an implementation of the variadic syscall(2) function, and a version for system calls that made as part of functions defined to be canc

Re:

[Anonymous Coward]

the guys at gnu know a thing or 2 about compilers and libraries

You obviously never worked on or looked at their source code.

glibc is horribly bloated

[uhmmmm]

The first priority on musl is correctness, and they will take a hit to size and speed if that's what's necessary to achieve it. But thus far, they've been doing a good job of achieving correctness without introducing too much bloat.

Take a look at their page on bugs found while developing musl [musl-libc.org], and you'll find that they've found and reported quite a few bugs in glibc where glibc had been "cutting corners".

Re:glibc is horribly bloated

[Just Some Guy]

LOL Drepper. He had a free pass to be an abrasive jerk for years because of his supposed dedication to perfection and uncompromising quality. In retrospect, maybe he was just a jerk to shut down people who wanted to examine his work more closely than he liked.

Re:glibc is horribly bloated

[dalias]

I've submitted at least two bugfix patches to glibc where the diff was 100% "-" lines for things Drepper added. I believe they were all eventually committed. And thankfully this is the one type of glibc patch submission that doesn't require having a copyright assignment on file with the FSF. ;-)

Re:glibc is horribly bloated

[Just Some Guy]

You're doing God's work, son.

Re:

[Samantha Wright]

You know it's a problem when... [sourceware.org]

Re:

[Raenex]

Wait, it says "RESOLVED FIXED", does that mean Red Hat fired him and revoked his commit access?

Re:

[Tough Love]

He became a vp at Goldman Sachs. Where I suppose he fits in well.

Re:

[Dr.Dubious DDQ]

The chart [etalabs.net] shows a few things, though I notice they don't include comparison to the full glibc itself.

Re:Either gnu libc is hideously slow and bloated..

[dalias]

At the time the comparison was made, glibc was essentially unmaintained and Debian-based distributions were using the eglibc fork. Now that glibc is under new leadership, eglibc is being discontinued and the important changes have been merged back to glibc upstream. So when I update the chart's quantitative comparisons, it will be for glibc rather than eglibc. The main things that will change when I do are significant increases in size (especially since I seem to have under-measured eglibc's totals) and possibly some improvements in performance. In terms of all the other qualitative comparisons, glibc remains about the same place it was before.

Re:

[jandrese]

Debugging features: no no no yes

WTF does this mean? I'm sure as hell not developing against a libc that doesn't have debugging hooks. This can't be what it means.

Re:Either gnu libc is hideously slow and bloated..

[dalias]

It doesn't mean you can't use gdb, just that libc itself does not try to double as a debugging tool. This is actually a security consideration. For example, glibc prints debugging information if it detects corruption in malloc. But if there's already memory corruption, you have to assume the whole program state is inconsistent; the corruption may be intentional due to the actions of an attacker, and various function pointers, etc. may have been overwritten. Continuing execution, even to print debug output, risks expanding the attacker's opportunity to take control of the program.

FWIW, musl does detect heap corruption. The difference is that it immediately executes an instruction that will crash the program rather than trying to continue execution, make additional function calls that go though indirection (the PLT) and access complex data structures, etc.

Re:

[uhmmmm]

I'm sorry, this sounds like a poor rationalization for lack of useful functionality. By this logic, you should crash the program without warning whenever invalid input is detected - it could be an attack since no program should ever provide invalid input to a function. In real life, programs have tons of bugs and diagnostic messages are hugely useful in identifying and then fixing them. Especially since the vast majority of programs are not used in a context where an attack can occur.

A 'paranoid' mode with this behavior may make sense for some people. Most people, especially those in the process of developing the software, would prefer diagnostics when things go wrong.

I disagree. There is a big difference between invalid input to a function (eg trying to convert "abc" to an integer) and a memory corruption bug. In the former case, you can return an error to the caller, and if they were written with enough attention to detail, they can fix the problem and move on, or ask the user for actually valid input, or whatever followup action may be appropriate.

In the case of a memory corruption bug, there is no way to correct the problem and move on. By the time you detect t

Re:

[dalias]

Perhaps you should read this: https://twitter.com/solardiz/s... [twitter.com]

Re:

[FatdogHaiku]

Don't measure the knowledge of the gnu guys based on your own lack of it.

Why not? It's exactly how we operate our political... oh, wait...

Re:

[Darinbob]

Just look at typical GNU code though. It's well written but it's not small, and often not efficient. Much of this is due to accretion over time, however there also is a certain style that the programs follow. Thus the parodied GNU HelloWorld program. Glibc makes an implicit assumption that it is being used on a fast computer with lots of memory (ie, a PC or minicomputer). This is perfectly normal, however it leads to a different sort of optimization than you would find for embedded systems or small com

Re:

[dalias]

Someone with mod points, please mod up the parent post. Even if you disagree with it, it's informative about one of the big issues in glibc that musl does differently: musl's snprintf and dprintf, for example, are async-signal-safe. Roland McGrath, who holds claim to being the "inventor" of dprintf and author of the original implementation in glibc, has stated that he intended for the function to be async-signal-safe or at least close to it, and that later introduction of dynamic allocation is a bug (which

pkgsrc test results

[staalmannen]

For those curious about which "5000 packages" that build with musl, there is the awesome automated pkgsrc tests published: http://wiki.musl-libc.org/wiki... [musl-libc.org]

Re:

[jandrese]

% ./configure checking for C compiler... gcc checking whether compiler is gcc... yes checking whether to build musl-gcc wrapper... yes checking target system type... amd64-undermydesk-freebsd ./configure: unknown or unsupported target "amd64-undermydesk-freebsd"

:(

I thought this might be helpful in those cases where something doesn't like llvm libc, but no such luck. It also appears to lack c++ support, which is a pretty big caveat in this day and age.

Re:

[dalias]

The problem appears to be that "x86_64" is identified by your compiler as "amd64" in the machine tuple. This is easily fixed by adding --target=x86_64 (the name musl knows it by) on the configure command line. I don't see any reason we can't add "amd64" to the detection logic in configure too, so this should work better for you in a future release.

Re:

[jandrese]

Hmm, well that got it built, but it still doesn't work.

% /usr/local/musl/bin/musl-gcc hello.c
/usr/local/musl/lib/libc.so: undefined reference to `isinf'

I didn't see any obvious errors while it was building, but there were like a million lines of buildscroll to go through, and it would have been so easy to miss one. There's probably just enough issues with this to make it not worth it sadly.

Re:

[dalias]

There is no isinf symbol or reference to one in musl, so I think this is something to do with your toolchain (a BSD-packaged version of LLVM that tries to make itself look like gcc?). Pretty much all of your concerns (including "lack of C++") could be solved by building a toolchain to target musl (note: uClibc and glibc make you do this anyway; musl is fairly unique in providing a way, albeit sometimes clunky, to use the new libc without a new compiler toolchain). If you want to do that or proceed trying to

Re:

[savuporo]

Maybe size, too. Minimal statically linked GLIBC based executable was about 100K or more on ARM last time i checked, pulling in crap related to io, locales etc, that were never even referenced from the code. Bionic was much better.

define _GNU_SOURCE

[cyberthanasis12]

I downloaded the library to see some random code. Here is the very first file I (randomly) chose (putw.c):

#define _GNU_SOURCE
#include
int putw(int x, FILE *f)
{
return (int)fwrite(&x, sizeof x, 1, f)-1;
}

Cheers.

Re:

[kthreadd]

Sounds reasonable since this library is mostly focused on GNU/Linux and not just POSIX compliance.

Re:

[dalias]

putw is a nonstandard functions and used by basically nothing, so a simple, obviously does-what-the-man-page-says solution in terms of another well-tested function is preferable to repeating the locking, buffer manipulation, etc. logic in a place that's unlikely to ever get tested.

Re:

[QuietLagoon]

and the problem with that code is...?

Re:

[fph il quozientatore]

Clearly, it should've been _GNU_LINUX_SOURCE.

Re:

[uhmmmm]

putw is a non-standard function that musl's headers only expose to programs when they define _GNU_SOURCE.or _BSD_SOURCE. The file that actually implements it, therefore, needs to define one of these in order for the header to expose the declaration, which allows the compiler to verify that the type signatures of the declaration and the definition match.

Re:

[flargleblarg]

Having knowledge that EOF == -1 is disgusting. And using it in a formulas? Even more disgusting. IMHO, that code makes me sick. I would write it instead as:

return (fwrite(&x, sizeof x, 1, f) == 1)? 0 : EOF;

which to me is much clearer.

Re:

[flargleblarg]

Actually, I would write it like this:

int putw(int x, FILE *f)
{
bool success = (fwrite(&x, sizeof x, 1, f) == 1);
return success? 0 : EOF;
}

Why is libm.a empty?

[Sponge Bath]

From the FAQ:

On musl, the entire standard library is included in a single library file — libc.a for static linking, and libc.so for dynamic linking. This significantly improves the efficiency of dynamic linking, and avoids all sorts of symbol interposition bugs that arise when you split the libraries up — bugs which have plagued glibc for more than a decade.

Bringing it all together? That's why they call it the love musl.

Re:buffer overflow in printf ... great for securit

[dalias]

Unlike some projects, we fully disclose bugs that might be relevant to security. In this instance, the bug could only be triggered by explicitly requesting sufficiently many decimal places (16445 for ld80) and printing a denormal long double with the lowest bit set, as in:

printf("%.16445Lf", 0x1p-16445);

In addition, even when triggered, it only wrote past the end of the buffer by one slot, and we were unable to get it to overwrite anything important like a return address (of course, what it overwrites depends on the compiler, so in principle it could).

Re:

[strikethree]

Unlike some projects, we fully disclose bugs that might be relevant to security.

Thank you. As a security guy, knowing that the disinfectant of sunlight is illuminating your project, I am willing to spend more time examining and using your project. I hope your project becomes the default libc everywhere.

Re:Brain damaged project

[pe1rxq]

Have you ever looked at static linking in detail?
A .a file is basicly a collection of .o files. The linker only links those that are needed.
So they have a single .a file instead of two or more .a files. This allows them to prevent difficult interdepencies between those .a files.
The end result might still be a very small subset of the complete library.

Re:

[dam.capsule.org]

As far as I know, the whole .a file gets linked in each time unless you use -fdata-sections when compiling and -Wl,--gc-sections when linking.

Re:

[porges]

No. You're thinking of the fact that once the linker marks a .o as required, it brings in all of that .o file unless you provide those flags you mention. But the point is definitely that only the .o files that are needed get linked into the final object model. Just do a gcc of a simple "hello world" program and then look at the a.out's size; it won't be anywhere near as big as libc.a. Also, nm a.out will show you the relatively few symbols in the a.out file.

Re:

[Qzukk]

The .a file is an archive of the individual .o files, only the individual .o files that are actually referenced get linked into the final executable. See also:

ar t libc.a

re: Brain damaged project

[uhmmmm]

Where does it say you have to link the whole thing into your application? Musl supports dynamic linking just fine. The musl developers do have a preference for static linking, so they have better support for it than glibc (see their size comparisons [etalabs.net] of static linked programs on musl and glibc, for instance). But that doesn't mean you have to use it.

The bit about aiming for correctness is correctness of musl itself. Of course they can't, in general, guarantee that you will write your own code correctly. In theory, they could split the math library out and force you to link against it correctly. But what would be the point? To arbitrarily break broken programs, while having no impact on correct programs? It would also have several downsides.

Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically, which eliminates a small window during upgrade where you might start a new program and have it break because it gets conflicting versions of these components.

There is also code within the main C library (for example, the code to format floating point numbers in printf) which benefits from being able to call functions that are part of the math library.

Re:

[serviscope_minor]

Musl is the only C library I'm aware of which allows the entire C library ecosystem (C library, math library, threading library, dynamic linker, and some others probably) to be upgraded atomically,

GLIBC allows this. You can definitely bring in new versions of all of those.

Re:

[dalias]

There is a way to upgrade glibc atomically, but it's a big hack, and even still it doesn't achieve the goal. The way it would work is to have /lib be a symlink to a versioned directory, and atomically replace (via rename()) the symlink with a symlink to the new directory. However, even if the replacement is made atomically, you still have the situation that the dynamic linker can load libc.so before the replacement is made and libpthread.so after it's made, resulting in mismatching versions.

Is it all about the license?

[jimwelch]

The first thing I saw was MIT vs GPL. What is the difference between the two?

Re:

[Githaron]

GPL requires you make your chances available under the GPL license while MIT makes almost no requirements.

Re:

[Archangel Michael]

http://stackoverflow.com/quest... [stackoverflow.com]

Of course Google it your self next time.

Re:

[jimwelch]

My sarcasm tag did not get passed on!

Re:

[swv3752]

MIT allows one to take your code and do what they will, including wrapping it up in a proprietary license. GPL requires that if one takes code, makes changes and distributes, they need to make the sourceof thsoe changes available to those they distribute the compiled or source code to. An example of taking MIT licensed code is what Microsoft did with BSD networking code and kerberos. The changes Microsoft did to BSd to make it work in Windows are lost to the community, including any potential bug fixes a

Re:

[unixisc]

What is the essential difference(s) b/w MITL and BSDL?

Re:

[dalias]

If you're talking about modern BSD licenses, basically there's no difference but the wording. Some older BSD licenses were mildly more restrictive, most notably the ones with the advertising clause that technically conflicts with the GPL.

Re:

[vilanye]

glibc is LGPL, so you can dynamically link to it if you don't want your app to be GPL'd.

Re:

[LDAPMAN]

That Devs are "falling all over it to provide code" is the point. Permissive licenses are desirable to a lot of people.

Re:

[marcello_dl]

Yes, people who want to avoid the requirements of the GPL, which asks simply for letting people get advantage of the code you distribute as you got advantage of the code you modify. "Freely you have received, freely give" (Matthew 10). Therefore if you love Jesus you follow the GPL, if you don't believe in god you follow the atheist Richard M. Stallman's license. Else you are obviously wicked.

Re:

[thevirtualcat]

If you're a developer working for a company and you have your choice between an MIT|BSD library and a GPL library that, on a technical level, work equally well, it's a hard sell to choose the GPL library.

Consider...

"Well boss, if we use libfoo, we'll have to disclose our source code since it's GPL. There are ways around it by doing things like writing LGPL wrappers and dynamically linking it, but we'll have to distribute THAT source code, instead. Plus, you may want to run this by legal, since the developer

Re:

[thevirtualcat]

Ah, so it saves them the trouble of writing the LGPL wrapper around it. Good to know.

Re:Reinventing GPL wheels

[dalias]

The main effect of glibc being LGPL is not that companies don't use it, rather it's that nobody making non-free software is willing to static-link it, so you end up with versioning hell. glibc partially solves this problem with symbol versioning, but the solution actually makes the problem worse in other cases: for example, in order to provide a binary that runs on systems with older glibc, people making binaries intentionally link against an older glibc, using the outdated/bug-compatible symbol versions instead of the up-to-date ones.

Of course if your goal is to make sure non-free software is always breaking and giving people problems, that's a potential benefit of the LGPL.

With musl, all you have to do to make a binary that works with older versions of the shared libc is avoid using functionality that was introduced in later versions. Or you can just static link and have it work everywhere.

Re:

[dalias]

BTW, in case anyone thinks I'm making up the thing about intentionally linking to ancient glibc, see this: http://www.crankuptheamps.com/... [crankuptheamps.com]

Re:

[epyT-R]

Except that you're wrong. If you change the library itself you'd have to release the patches. If you're just dynamically linking to it, you don't. A more appropriate question your boss might ask is "Why the hell are you putting our 'secrets' into the libc?"

Link to comparison chart

[paulpach]

Here is a link to the comparison chart [etalabs.net] mentioned in the description.

Why should I drop glibc?

[peppepz]

Forking the Linux userland yet again should have some serious motivations behind it. I can't find them neither in the benchmarks nor in the feature comparisons provided here.

Re:Why should I drop glibc?

[dalias]

If you don't want to switch, that's fine. You're still getting the benefits of musl, because competition has driven the glibc developers to fix, or at least study how to fix, a number of longstanding bugs in glibc.

Re:

[peppepz]

The libc is not a library like all the others. Proposing a binary- and source- incompatible replacement for glibc, as is being done here, means to partition the Linux userspace, both binaries and source code, into two isolated subsystems. Something that we are already suffering with Android. This is not a benefit, this is a damage for the Linux community as a whole, and it will hurt me even if I don't want to switch. Casual PC users already run into enough problems when switching to Linux; asking them to ch

Re:

[Anonymous Coward]

You get your binaries from distributions anyway and with musl your closed source bits can just statically link safely libc and live happy and isolated.

Re:

[peppepz]

You get your binaries from distributions anyway

No, I get binaries from wherever I want and it works.

and with musl your closed source bits can just statically link safely libc and live happy and isolated.

I can't live happily without shared libraries. They were invented for good reasons tens of years ago and have been used extensively ever since. Think about the "bloat" of statically linked executables and the fact that they don't get updates of the linked-in library code (including security fixes).

Re:

[peppepz]

Virtually all binary software is distributed in enormous tarballs containing their own libc, and every other library they use, and a bunch they don't simply because static linking doesn't work against glibc properly (and violates the license for non-free software).

Please don't spread false information this way.

Take Firefox for example, from Firefox.org, not the version shipped with your distro. Every Firefox tarball includes their own build of GTK, GDK, glibc, libnspr, etc.

Yes, let's take the version from firefox.org that I'm using right now.

$ ldd /opt/firefox/firefox-bin
linux-gate.so.1 (0xb77bb000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb776b000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7765000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb775c000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7675000)
libm.so.6 => /lib/i386-linu

Re:

[peppepz]

Actually it is.

It's linked by any executable on your system and it has the role of loading every single dynamic binary that you have installed, including init. It's special.

I have both musl and glibc on my systems, and they have different filenames, so I can have both installed without conflicts.

Of course you can have both installed, but not without conflicts, you must be very careful to avoid the sea of conflicts that arise when you have two incompatible libraries with the same name.

Programs interoperate through IPC and the filesystem, so having programs built against different libc on the same system is not a problem.

You'll have to:
- duplicate every single binary and library to have libc and musl versions;
- ensure that the version of each binary is the same for its libc and

Re:

[peppepz]

Except statically linked binaries. Those were linked at build time, but they don't invoke the linker when they are executed. Guess what I use musl for? Building static binaries.

But you're changing the goalpost now. What I said was troublesome was using musl (or anything else, if glibc-incompatible) as a replacement for glibc. Using it for selected static binaries that you build yourself is another thing.

Nope. Binaries I only need one or the other, not both. Libraries only when I need a musl version of a library.

That's because I was talking about replacing glibc with musl, and be able to run binaries, over which you have no control, written for any of the two libraries. Which is the only scenario that would makes final users happy, should glibc coexist with musl.

No. Only for shit software that doesn't have any kind of protocol.

Again, that's stuff that is

Missing the only useful comparison.

[Anonymous Coward]

The compare page is missing the only other entry I wanted to see.... and that is, BSD libc. This is widely used by QNX (Blackberry) and probably all kinds of other vendors. I image Apple has their own fork.

The others aren't comparable because they're copylefted, so cannot be used everywhere like musl and BSD libc can.

Re:

[epyT-R]

Well they can, but if the vendor distributes a modified version of glibc, they have to release the patches they made to it. I really don't see what the big deal is as there's no reason to hide secret bits in the libc. The proprietary magic is all in the custom programs running on top of it.

Re:

[psmears]

The compare page is missing the only other entry I wanted to see.... and that is, BSD libc. This is widely used by QNX

No, QNX has its own libc - the microkernel architecture means the system call interactions work substantially differently from traditional Unix/Linux/etc.

Compared to Bionic

[SDPost]

I wonder how small Musl is in comparison to Bionic which is really, really small.

Re:

[dalias]

I really want to add a Bionic comparison, but in order to be comparing apples with apples (or non-apples with non-apples, pardon the pun) we need an x86 build of Bionic, or need to re-do all the other libcs' figures for arm. I've been looking for a way to build Bionic outside of the Android build system and use it on non-Android systems, and the gentoobionic repository at https://github.com/gentoobioni... [github.com] looked promising, but I couldn't get it to work. It also may be much larger than the official Bionic.

Re:

[staalmannen]

also klibc and newlib could be interesting. Newlib especially since it is used for its portability and to make experimental OSes, klibc for being extremely small and minimal

Re:

[epyT-R]

I'm not sure why this was voted down, but there is a point here. If the future of OSS belongs to licenses that don't protect the continued openness of source, OSS authors are effectively working for free and competing with those who take their code and wrap it up in proprietary licenses.

It's ok to charge cash for binaries and/or source. So why is it so terrible to 'charge' source for source?

Re:

[Anonymous Coward]

Thats not true.

Nearly every time I used a BSD licensed program for some project that left my computer I contributed bugfixes and sometimes features back (if I added features, often just used unmodified).

The alternative with GPL (in the embedded world at least) is that most companies say f*ck off and license some proprietary system. The value of the source to some product (unless it's some disposable thing such as a home router) is much much higher than the cost of licensing some components. The community th