3 ms·

He briefly mentions dietlibc ("not evolving anymore") and ulibc. I think he'd be better off contributing to those projects (or musl). You might start off thin

by rwmj 4y ago

He briefly mentions dietlibc ("not evolving anymore") and ulibc. I think he'd be better off contributing to those projects (or musl). You might start off thinking you only need system calls, but at some point you'll want to print something, and even a basic 'printf' will be very handy. FWIW I have built a program that needs a tiny initramfs[1] and we've found that dietlibc and musl worked really well producing very tiny binaries. glibc is terrible - it links huge amounts of code into even the smallest program. [1] https://github.com/libguestfs/supermin/blob/86fd6f3e86ab99d54a22b475aecccfc19bdff07e/README#L149 https://github.com/libguestfs/supermin/blob/86fd6f3e86ab99d5...

synergy20 4y ago
why dietlibc and uclibc instead of the modern musl?
- rwmj 4y ago
  He doesn't mention musl in the article, but in my experience musl would also be an excellent choice.
  - wtarreau 4y ago
    Hi! article author here, I can respond to a few questions. I didn't know about musl by then and it could definitely have oriented my choices differently. However after I started to use macro-based syscalls, I found there were very convenient benefits in not having to compile a libc for some cases. Not only static functions are optimized away when not used, but in addition you can use any toolchain, you don't have to fiddle with wrappers for dietlibc/uclibc nor include them with your toolchain. For regular sized projects I would encourage anyone to use musl of course. But for tiny stuff like in the kernel that relies on a bare-metal compiler and a handful of syscalls and very limited stdlib functions, nolibc is convenient.
- jchw 4y ago
  Agreed, I think musl is the obvious choice actually: it may be newer (at least I think it's newer) but it's pretty solid, and it's use in Alpine Linux has probably helped it mature and gain ecosystem support, especially as Alpine gained popularity for Docker/OCI images due to its size efficiency.

by rwmj 4y ago

synergy20 4y ago

why dietlibc and uclibc instead of the modern musl?

rwmj 4y ago
He doesn't mention musl in the article, but in my experience musl would also be an excellent choice.
- wtarreau 4y ago
  Hi! article author here, I can respond to a few questions. I didn't know about musl by then and it could definitely have oriented my choices differently. However after I started to use macro-based syscalls, I found there were very convenient benefits in not having to compile a libc for some cases. Not only static functions are optimized away when not used, but in addition you can use any toolchain, you don't have to fiddle with wrappers for dietlibc/uclibc nor include them with your toolchain. For regular sized projects I would encourage anyone to use musl of course. But for tiny stuff like in the kernel that relies on a bare-metal compiler and a handful of syscalls and very limited stdlib functions, nolibc is convenient.
jchw 4y ago
Agreed, I think musl is the obvious choice actually: it may be newer (at least I think it's newer) but it's pretty solid, and it's use in Alpine Linux has probably helped it mature and gain ecosystem support, especially as Alpine gained popularity for Docker/OCI images due to its size efficiency.