Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Open Source Linux

GNU C Library Alternative Musl Libc Hits 1.0 Milestone 134

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

    • by staalmannen ( 1705340 ) on Thursday March 20, 2014 @10:22AM (#46533917)
      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: (Score:3, Insightful)

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

    • by uhmmmm ( 512629 ) <> 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 [], and you'll find that they've found and reported quite a few bugs in glibc where glibc had been "cutting corners".

    • The chart [] shows a few things, though I notice they don't include comparison to the full glibc itself.
      • 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 jandrese ( 485 )

        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.

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

    • 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

  • 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: []
    • by jandrese ( 485 )

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

      • by dalias ( 1978986 )
        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.
        • by jandrese ( 485 )
          Hmm, well that got it built, but it still doesn't work.

          % /usr/local/musl/bin/musl-gcc hello.c
          /usr/local/musl/lib/ 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.

          • by dalias ( 1978986 )
            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
  • define _GNU_SOURCE (Score:3, Interesting)

    by cyberthanasis12 ( 926691 ) on Thursday March 20, 2014 @10:34AM (#46534077)
    I downloaded the library to see some random code. Here is the very first file I (randomly) chose (putw.c):

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

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

    • by dalias ( 1978986 )
      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.
    • and the problem with that code is...?
    • by uhmmmm ( 512629 )
      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.
    • 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.

      • 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;

  • by Sponge Bath ( 413667 ) on Thursday March 20, 2014 @10:37AM (#46534125)

    From the FAQ:

    On musl, the entire standard library is included in a single library file — libc.a for static linking, and 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.

  • The first thing I saw was MIT vs GPL. What is the difference between the two?
    • GPL requires you make your chances available under the GPL license while MIT makes almost no requirements.
    • []

      Of course Google it your self next time.

    • My sarcasm tag did not get passed on!
    • by swv3752 ( 187722 )

      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

      • What is the essential difference(s) b/w MITL and BSDL?
        • by dalias ( 1978986 )
          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.
    • glibc is LGPL, so you can dynamically link to it if you don't want your app to be GPL'd.

  • by paulpach ( 798828 ) on Thursday March 20, 2014 @11:02AM (#46534387)
    Here is a link to the comparison chart [] mentioned in the description.
  • 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.
    • by dalias ( 1978986 ) on Thursday March 20, 2014 @12:10PM (#46535165)
      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.
      • 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
        • by 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.

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

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

    • by epyT-R ( 613989 )

      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.

    • by psmears ( 629712 )

      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.

  • I wonder how small Musl is in comparison to Bionic which is really, really small.
    • by dalias ( 1978986 )

      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 [] looked promising, but I couldn't get it to work. It also may be much larger than the official Bionic.

    • 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

Lavish spending can be disastrous. Don't buy any lavishes for a while.