Musl libc is a more preferable option if security and speed are important to you, compared to glibc, but is this currently the case? Do most applications still not work on musl? And how effective is gcompat?
You must log in or register to comment.
musl is very cool and has very specific use cases. workstations are not one of them. you won’t be able to install drivers for gpus for example.
As somebody with a dozen workstations running MUSL, I disagree. But you are going to want to use a performant allocator.
The issue with C libraries is that you will have problems using pre-compiled binaries that are dynamically linked against a different C library.
If I gave you a binary dynamically linked against MUSL, it would not work with Glibc either. It is not some kind of MUSL deficiency.
The issue of course is that most pre-built proprietary software was built against Glibc. The proprietary NVIDIA drivers are a good example. But all the in-tree GPU drivers are fine.
There is gcompat which pretends to be Glibc and forwards calls to MUSL from software that is trying to call Glibc. That may be enough to make things work sometimes.
So there are two answers to “what works with MUSL?”.
The first answer is that, if the software is linked with MUSL when it is built, almost everything works. A musl based distro could have a huge package library.
The second answer is that, if you are trying to run software that was dynamically linked against a different C library when it was compiled, then basically nothing works. This is no different than missing any other dependency. Gcompat is a hack that makes programs use MUSL when they try to call Glibc, and that will work some of the time.
As an aside, MUSL allows you to statically compile programs which means they include the C library in their binary. This allows these programs to run regardless of what C library is available on the local system. For this reason, MUSL is often used to create static binaries even on systems that use Glibc. Pacman on Arch is a good example.
The GPU driver issue would really only be a problem for Nvidia stuff.
Saying musl is preferable if speed is important is a bit…loaded. It’s not always untrue, but it often is.
As a libc, musl has a much smaller footprint than glibc, so a computer which is short on memory capacity, memory bandwidth, or cache size could absolutely see a performance benefit. The flipside to this is that a lot of the ‘bloat’ in glibc are performance tricks including lots of architecture specific code.
As others have mentioned, the malloc implementation is less than ideal and can slow down highly threaded & memory intensive applications.
I work on a musl-based embedded distribution for my day-job, and also quite like using it personally for arm boards and my old ThinkPad. I wouldn’t really use it for my workstation though.
As far as applications working with musl, it’s not uncommon to see glibc-specific code which would need to be patched out of some applications (systemd comes to mind).
Do you guys use the stock allocator?
Using mimalloc instead seems to work pretty well.
It does, I quite like mimalloc though I prefer to have programs compiled with their custom allocator rather than inserting them via LD_PRELOAD as I’ve found some issues when using it with programs like Firefox.
Chimera Linux builds MUSL with mimalloc. As a daily Chimera Linux user, I can say that Firefox works pretty well.
You may want to take a look at their configuration.
https://github.com/chimera-linux/cports/tree/master/main/musl
Personally, i prefer a smaller general codebase with equal speed vs. a bigger one with specific hacks and workarounds.
But honestly, at this level maybe for critical things like a high-security server (Alpine).
The line between what is a hack and what is basic performance optimisation is both subject to taste and use-case. Horses for courses, right?
Sure.
This doesn’t answer your question, I’m sorry, but I will say Void is an endlessly fascinating project
It works, but the memory allocator implementation is way too slower compared to glibc. This especially becomes a performance bottleneck if application does a lot of heap allocation/deallocation.
I think Musl is a better choice when you work on embedded, low-end devices, or statically linked/self-contained applications. For high performance workstation usage, I still prefer glibc.
The default allocator is very slow but it can be changed. Chimera Linux, for example, uses mimalloc which is very fast.
Btw, is it possible to chroot into a glibc sub-distro from a musl distro?
Yes
But I would just use Distrobox if you want to do that.
My distro is based on MUSL. I seem to remember finding something that would not build on it but I do not recall what that is. In addition to the thousands of packages I am using, I have compiled hundreds of applications. Compatibility is very high.
Certainly it is clear the “most applications” work with MUSL.
That is, the source code does.
gcompat is when you want to run something that is already a binary that wants to call into Glibc. I try to avoid that so I cannot comment much.
There is the odd time I have had a binary built for Glibc that I could not avoid. For example, bootstrapping .NET or the version of vcpkg that the Ladybird browser uses in its build system. To be honest, in those cases, I just reach for Distrobox and drop into a distro that has Glibc natively, like Arch. Or I might use a RHEL Distrobox for a commercial binary meant to target that distro.
Clearly running a binary without one of the dependencies it was built against is a problem no matter what library you are taking about. But if we are just asking what works on MUSL, I would say almost everything.
Google Crashpad is used for crash reporting by some program, and it can’t be built with musl. It also does not build in FreeBSD, and I suspect it only works with glibc outside of Mac OS, Windows, and Android.
I don’t use Google Crashpad but when did you last try it.
I just read a bug report that says it fixed building on MUSL in 2023. The fix was to comment out a reference to user_vfp in thread_info.h and to put the change in an #ifdef.
I assume this is in the mainline by now.
I think it was around the same time when I disabled it altogether in the Makefiles of some software. Let’s hope it’s upstream now.
I don’t recommend it because of the allocator but if you want to switch to musl, start by checking if the distro you will switch to has the software you need. Signal for example does not work. I have to use the flatpak.
Chimera Linux uses musl libc, Void Linux has the option of musl libc, and of course Alpine uses musl libc.
Gentoo also offers it as an option. If you’re very bored and curious about what doesn’t work under specific versions of musl, you can peruse the Gentoo compatibility tracker bugs..
So, 6 MUSL bugs for all of Gentoo?
And three of them are the same just for different versions of MUSL. And reading the bug report, it seems like a commit has been created and is awaiting review.
If all that is true, we have our answer. MUSL works with everything.
Not quite. Those are trackers: lists of bugs. If you open one, you’ll see a list of individual package bugs that are blocking these ones—up to a couple of dozen unresolved in some cases. Still, it isn’t that long a list, and a lot of the packages are minor or obscure.
Ah. Thanks.
The list is definitely longer than that. I switched to musl overlay about three years ago and I couldn’t daily drive it. I guess the six comes from no one is using it.
Gcompat is not very effective but most open source software works with minimal patching.
It works. Go ahead, try it.
but is this currently the case
sorry, is what the case?
