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.

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..

[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.

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: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: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:Reinventing GPL wheels

[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 has outright refused to sell non-GPL licenses..."

Versus...

"Well boss, if we use libbar, we can just use it since it's MIT. If we make changes to it, we should contribute them back, but we're not obligated to do anything except keep their copyright notice."

With that in mind, is it any wonder projects like llvm and musl are popping up and gaining the support of large companies that use them?

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: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: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.