Musl vs Glibc

This is one thing I have not seen a good answer for to be honest. And when there is situations like this the answer is always actually that "it depends" but yeah both are good in their own ways. But I prefer statically linked binaries more. They consume less Resident for the cost of greater file size on disk. RAM is not cheap but storage is, you can be good on that part. but this should not be done instead in a environment when you do not have more storage like on a VPS.

Nonetheless I have made one program called

bstatus

written in C which is a swaybar status generator that adheres to the

swaybar-protocol(8)

If you want, you can check it out. Configuration and installation is simple. I have built and tested the first few stages of bstatus with only the gcc compiler thinking that "yeah Glibc must be efficient!". Yeah honestly it is. The only problem: Glibc is too complicated, has way too many gcc-isms (flags), sometimes goes against the standard. If a project used Glibc extensions that only Glibc can understand, you /cannot/ just use "any" compiler. This is the problem. Just cannot use your favourite C compiler to compile this program.

If you are on a binary distro, you shouldn't find anything really wrong with it because compilation is all done by the repo owners not you. But if you are on gentoo. And especially gentoo with musl. I think you are going to have a hard time to compile packages that uses gcc extensions. Nonetheless, I think people will prefer to use Glibc instead only because of performance. So I think Glibc should be used on larger projects that require it. But then people who are on a musl based distro is going to hate that project using Glibc extensions and whatnot to squeeze performance out of the program.

The Glibc library is large. It has too much code. When doing statically linked binaries on Glibc, you cannot get a binary with as lower as a size that you could get with musl libc. Here is some comparison between musl and other compilers actually.

musl libc comparison

The smallest static C program is only 1.8K! On the other hand, with Glibc its a massive 662K that surely is going to ruin your storage really. And that has nothing to do with optimisations gcc provide. It is just a bad way to dump the entire standard library into the program. Even if you don't mention the stdio.h itself! What a mess. A static `"hello %d"` with printf, when compiled with Glibc again is 662K (because it again dumps the entire standard library for no reason), but musl only allows the definition of printf added to the program for it to work, only the necessary. musl handles statically linking better. While gcc handles optimisations better. The difference is little when the code is efficient itself (Meaning: We need actual programmers).

The suckless philosophy is neat. Less for more, and neat workflow. While I would want to use dwm instead of sway or smt. The problem is that DWM is fundamentally different than sway, which is a container based WM. Sway has too much stuff ig. There are some projects that doesn't support statically linked binaries at all, only because they use a library that does not have a static version of it. A huge problem.

Well... nothing to do about it. The choice should be given to the packager or the end user who wants to use his own compiler to compile it, even if its just Glibc in the end. Or... am I just naive?