3 ms·

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.

by fra 7y ago

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.

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.

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