Stories
Slash Boxes
Comments

SoylentNews is people

musl libc Reaches 1.0 Milestone

posted by LaminatorX on Thursday March 20 2014, @01:33PM   Printer-friendly
from the ilibc-ulibc-we-all-C-for-libc dept.

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

 
This discussion has been archived. No new comments can be posted.
musl libc Reaches 1.0 Milestone | Log In/Create an Account | Top | 37 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 0) by Anonymous Coward on Thursday March 20 2014, @06:28PM

    by Anonymous Coward on Thursday March 20 2014, @06:28PM (#19004)

    The GGP is probably some "programmer" who only writes in VM-languages with little real-world experience not having his hand held. That usually where most of these inane suggestions come from.

  • (Score: 1) by ArghBlarg on Thursday March 20 2014, @06:46PM

    by ArghBlarg (1449) on Thursday March 20 2014, @06:46PM (#19018)

    Wow. Just wow. Why don't you go home with your "air quote" ad-hominem attacks already?

    OK Mr. Coward, let's hear your better ideas. And "rewriting libc over-and-over again and patching holes after we find them, with no attempt to fix root causes" isn't an idea. I may not have any ultimate answers, but at least I'm trying to think about them.

    Fine, mentioning strlen() was probably a red herring -- that' not really an efficiency issue. But from a computational standpoint, it's still unncecessary (and yes I know compilers may optimize invariants like that in certain situations, buy why should that even be necessary?)

    I never said changing how strings were represented would be easy. It's easy to say in hindsight that radical things that turned out well were obviously good.. except it wasn't obvious unless someone did it. (See any successful wheel that's been rewritten 'just cuz' someone wanted to).

    BTW my experience is primarily with RTOS and embedded development, so I'm not totally clueless as suggested.