Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Musl-libc version 1.0.0 released

musl-libc.org

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Musl-libc version 1.0.0 released

#31

Post by [deleted] »

dalias wrote: post #20
noselasd wrote: post #18

Earlier quoted context omitted.

Is there any overview of differences/missing pieces in respect to glibc ? (I'd expect most of them are GNU extensions or or legacy, e.g. at a glance, no SunRPC, fts.h, obstack.h, fstab.h). And how is C11 library support ?

Some of these things are covered on the comparison page I did at http://www.etalabs.net/compare_libcs.html In regards to fts.h, the version in glibc is not even usable because it only works in 32-bit off_t mode, and stat() randomly fails in this mode due to modern inode numbers being 64-bit. See the recent thread on the glibc mailing list: https://sourceware.org/ml/libc-alpha/2014-03/msg00408.html and the bug tracker…

[deleted]

Re: Musl-libc version 1.0.0 released

#32

Post by hkphooey »

dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

Did you raise issues with the glibc team and submit patches etc... before deciding to create your own project?

Re: Musl-libc version 1.0.0 released

#33

Post by justincormack »

hkphooey wrote: post #32
dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

Did you raise issues with the glibc team and submit patches etc... before deciding to create your own project?

@dalias is very active on the glibc list. Back when he started it was in a dark period and not responsive to change. It is better now, but there is space for something as different as Musl.

Re: Musl-libc version 1.0.0 released

#34

Post by justincormack »

throwawayaway wrote: post #30
dalias wrote: post #29

Earlier quoted context omitted.

LD_PRELOAD alone wouldn't do it because glibc's dynamic linker is closely tied to glibc. In particular thread-local storage requires close cooperation between them. Likewise, musl needs its own dynamic linker. What could be done in theory is replacing /lib/ld-linux.so.2 with a symlink to musl. One of the long-term goals for musl is for this to actually work, at least for many programs. But right now there are a lot o…

Excellent response! I have a program that spends 10% of it's time in vfprintf for string processing, and I really think the program should not be spending that much time/any time there. I looked at the libc6 vfprintf implementation and it's pretty esoteric looking stuff. It might be worth my time using your library or something similar to swap it out.

Musl has the benefit of being very readable, and you can just use bits of code if you like due to the license.

Re: Musl-libc version 1.0.0 released

#35

Post by dalias »

hkphooey wrote: post #32
dalias wrote: post #15

Hi all. I'm the original author and maintainer of musl, and I'm happy to answer any questions anyone might have about the project. Glad to see so much interest!

Did you raise issues with the glibc team and submit patches etc... before deciding to create your own project?

At the time the project was started, Ulrich Drepper was the maintainer of glibc and the official response to any bug report was "STFU". So, no.

Aside from that, while a more permissive license was not part of my original goal or vision for musl, it's something that could never have happened by working on improving glibc. Right now we're facing a situation where Linux has been fragmented into a "GNU/Linux" minority made up of hackers' desktop PCs and enterprise servers, and an overwhelming Android majority. The latter is using a grotesquely incompatible, poorly designed, non-standards-conforming libc called Bionic, and if you want to run existing C programs on Android, you have to add heaps of #ifdef hackery to them to make them compatible with Bionic (much like the #ifdef hackery needed to make C programs work on Windows).

musl can provide a real, standards-conforming libc for use on Android that's still light and MIT-licensed (important because Open Handset Alliance members have a contractual obligation to Google not to add copyleft code to the system they distribute). This means, in theory, we can do away with the whole #ifdef mess and just run existing, portable software on Android. In short, it has the potential to free FOSS projects from getting bogged down in the maintenance burden of supporting yet another gratuitously-incompatible system (Android) in order to remain relevant.

Re: Musl-libc version 1.0.0 released

#37

Post by jokoon »

dalias wrote: post #22
jokoon wrote: post #19

wait, but I thought premature optimization was evil !

musl actually has very little in the way of optimization, premature or otherwise. Most functions are written to be as simple and direct as possible. Often but not always this gives near-optimal size and speed too. The places where more complex approaches are used are _mostly_ situations where the naive solution would have corner cases that fail or corner cases that have pathologically bad performance and could be use…

Isn't this implementation targeting embedded platforms ? I read it's reducing its memory footprint by using static linking...

Re: Musl-libc version 1.0.0 released

#38

Post by shaurz »

dalias wrote: post #35
hkphooey wrote: post #32

Earlier quoted context omitted.

Did you raise issues with the glibc team and submit patches etc... before deciding to create your own project?

At the time the project was started, Ulrich Drepper was the maintainer of glibc and the official response to any bug report was "STFU". So, no. Aside from that, while a more permissive license was not part of my original goal or vision for musl, it's something that could never have happened by working on improving glibc. Right now we're facing a situation where Linux has been fragmented into a "GNU/Linux" minority ma…

I would really like Android to switch over to Musl and drop Bionic, and eventually also drop SurfaceFlinger for Wayland and use an upstream kernel. I can dream...
Post reply on HN