Forgot your password?
typodupeerror
Open Source Linux

GNU C Library Alternative Musl Libc Hits 1.0 Milestone 134

Posted by Unknown Lamer
from the pry-glibc-from-my-cold-dead-ld.so dept.
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.
This discussion has been archived. No new comments can be posted.

GNU C Library Alternative Musl Libc Hits 1.0 Milestone

Comments Filter:
  • pkgsrc test results (Score:5, Informative)

    by staalmannen (1705340) on Thursday March 20, 2014 @10:15AM (#46533835)
    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]
  • by uhmmmm (512629) <{moc.liamg} {ta} {mmmmhu}> on Thursday March 20, 2014 @10:42AM (#46534189) Homepage

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

  • by uhmmmm (512629) <{moc.liamg} {ta} {mmmmhu}> on Thursday March 20, 2014 @10:46AM (#46534231) Homepage

    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.

  • by paulpach (798828) on Thursday March 20, 2014 @11:02AM (#46534387)
    Here is a link to the comparison chart [etalabs.net] mentioned in the description.
  • by uhmmmm (512629) <{moc.liamg} {ta} {mmmmhu}> on Thursday March 20, 2014 @11:10AM (#46534455) Homepage

    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.

  • by dalias (1978986) on Thursday March 20, 2014 @11:25AM (#46534641)
    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.
  • by dalias (1978986) on Thursday March 20, 2014 @12:23PM (#46535321)

    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.

(1) Never draw what you can copy. (2) Never copy what you can trace. (3) Never trace what you can cut out and paste down.

Working...