Slashdot Mirror
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.
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.
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...
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.
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.
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.
You obviously never worked on or looked at their source code.
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".
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
For every problem, there is at least one solution that is simple, neat, and wrong.
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.
Here is a link to the comparison chart mentioned in the description.
Have you ever looked at static linking in detail? .a file is basicly a collection of .o files. The linker only links those that are needed. .a file instead of two or more .a files. This allows them to prevent difficult interdepencies between those .a files.
A
So they have a single
The end result might still be a very small subset of the complete library.
Secure messaging: http://quickmsg.vreeken.net/
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 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.
http://stackoverflow.com/quest...
Of course Google it your self next time.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
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?
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).
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.
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.
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.
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.
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 check which libc is required before installing a program is the kind of nuisance that makes them run away. I don't contest musl developers' freedom to code whatever they want, and I welcome their efforts. I do contest the stance to replace glibc with an incompatible library, whomever it comes from.
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.
/opt/firefox/firefox-bin /lib/i386-linux-gnu/libpthread.so.0 (0xb776b000) /lib/i386-linux-gnu/libdl.so.2 (0xb7765000) /lib/i386-linux-gnu/librt.so.1 (0xb775c000) /usr/lib/libstdc++.so.6 (0xb7675000) /lib/i386-linux-gnu/libm.so.6 (0xb762f000) /usr/lib/libgcc_s.so.1 (0xb7614000) /lib/i386-linux-gnu/libc.so.6 (0xb746a000)
/lib/ld-linux.so.2 (0xb77bc000)
$ ldd
linux-gate.so.1 (0xb77bb000)
libpthread.so.0 =>
libdl.so.2 =>
librt.so.1 =>
libstdc++.so.6 =>
libm.so.6 =>
libgcc_s.so.1 =>
libc.so.6 =>
See? It's using my libc, so what you said is completely incorrect. Shall we see if it uses its own GTK library as you've said? I'll past the ldd result here: http://pastebin.com/UsP0MHUe , so you can see for yourself that firefox uses the system libraries instead.
Because dynamic linking is so horribly broken on Linux that is the only way it could possibly work on more than one distro.
Dynamic linking on Linux is state-of-the-art. If it doesn't work for you, look for responsibilities somewhere else than the operating system. If anything, it's static linking which is badly supported (by glibc, not by Linux).
SORRY.
...