3 ms·

I didn't see this addressed in the post, but why not musl?

• zamadatix 7y ago
  The original post linked in the opening covers some of the search and reasoning.
  • justincormack 7y ago
    it says "A more lively project; still, definitely targets systems with a real Linux kernel." but actually people are using Musl for other use cases. And it is BSD licensed, and very high quality.
    • stefan_ 7y ago
      Okay, what good is any of that if musl literally does not compile without Linux headers? This is for systems that are at best a small RTOS, and there is no standard for what those operating systems offer to a libc.
      • justincormack 7y ago
        Musl upstream only supports Linux, but it is so easy to port that there are large numbers of ports to non Linux environments.
    • digikata 7y ago
      There were other considerations against musl there. I'd summarize them as targeting a desktop/server with kernel level system, or at least a mid-to-high end embedded system, has different code, memory, and optimization tradeoffs than the smaller embedded systems that seem to be targeted with picolibc.
• fra 7y ago
  For what it's worth: musl is much larger than newlib-nano or picolibc. Most of the embedded projects I've worked on could not afford to use musl.
  • weberc2 7y ago
    So the inverse--could an OS distribution like alpine profit from using picolib instead of musl? What would be the tradeoffs (presumably performance for size, but to what degree)?
    • simcop2387 7y ago
      Along with performance, there's probably other ABI issues and maybe even API extensions to the C library that just aren't present in these tiny implementations. You can work around the ABI stuff by recompiling with the new c library of course, but that won't work if you've got a closed source binary or if the software needs something not provided.
  • wahern 7y ago
    picolibc$ find . \( -name test -o -name testsuite \) -prune -o -name \*.c -exec cat -- {} + | wc -l 259227 picolibc$ find . \( -name test -o -name testsuite \) -prune -o -name \*.h -exec cat -- {} + | wc -l 60588 musl$ find . -name \*.c -exec cat -- {} + | wc -l 60697 musl$ find . -name \*.h -exec cat -- {} + | wc -l 37889 Those figures are sufficiently far apart that I don't think we need to quibble about comments. Whatever is causing those huge numbers for picolibc (architecture optimized function variations? per file license preambles?), suffice it to say that it's debatable the extent to which newlib or picolibc is smaller or simpler than musl, if at all. musl is maybe more ambitious in terms of full and correct POSIX compliance, but the code base is very clean and concise. For example, for locale support they keep things very simple by only supporting UTF-8. Unlike picolibc, musl includes a full ELF runtime dynamic linker, full pthreads library (with correct cancellation semantics!), and up-to-date wrappers for all the esoteric Linux syscalls, yet still clocks in at ~60k lines of C source files at most. It would be fairly trivial to remove those things, precisely because of how well structured and straightforward the code is. musl also builds using a single, simple Makefile musl$ wc -l Makefile 235 Makefile compared to the supposedly simpler and cleaner meson build: picolibc$ wc -l meson.build meson_options.txt 282 meson.build 132 meson_options.txt 414 total If I was working on an embedded project, I know which build I'd prefer to hack on.