What is the problem with `musl`?
Closed this issue · 6 comments
When a program is statically linked, it should be self sufficient. Why self-sufficient libc program is better than musl?
The issue is that on some distributions -- such as openSUSE and SUSE Linux Enterprise, as well as probably RHEL -- musl isn't packaged (especially not as part of the Rust toolchain). There's nothing wrong with musl per-se (it does have some quirks but they don't matter to us here), it just means we can't use it for quite a few distributions.
And this wasn't for lack of trying -- my first implementation of this project was in Rust, and I ran into many issues trying to package it with static compilation using the Rust toolchain on several distributions. To be fair to Rust here -- static compilation is something distributions generally are quite unhappy about so it's not surprising that doing it in a fairly new language (to distributions at least) wasn't going to work well.
The Rust standard library depends on a libc for many things (the most obvious one is the memory allocator, but there's loads of other things like name lookups through NSS which needs to be done through shared libraries). As a result, all Rust programs have a dependency on some libc.
I can't think of a language which doesn't have a dependency on some libc -- even Go (which prides itself on embedding everything in its binaries including the Linux syscall ABI) depends on libc. Either way, this is a more general property of Rust -- it's not something that a small project like this can fix.
That's interesting. Are there any resources that describe how that libc dependency happens in depths? I would really be amused to explore the graph of those "dependency infection" pathways.
I don't know of any off the top of my head, unfortunately. Most of my knowledge in this area is based on more general knowledge and experience (for instance, debugging a networking issue in Go only to discover that the relevant networking code is actually in glibc). You could try diving into the code of different languages' standard libraries, though that does require some knowledge of the language in question.
Hopefully I've answered your original question, so I'll close the issue.
I found some threads from 2016 in Rust internals, but couldn't find any implemented solution (including OS written inn Rust). From the recent developments this thread seems to be reference point - rust-lang/rfcs#2610