Quoting the official site:
musl is a new standard library to power a new generation of Linux-based devices. It is lightweight, fast, simple, free, and strives to be correct in the sense of standards-conformance and safety.
musl on Void Linux
Void officially supports musl by using it in its codebase for all target platforms, except i686. As well, all the packages provided through our official repositories are available with musl-linked binaries in addition to their glibc counterparts. To our knowledge, this is something unique and a departure from the myriad of GNU/Linux distributions that tend to stick to the beaten path, but it is fitting with our purpose — to offer the building blocks that enable everyone to enjoy the best possible experience on their platform of choice, leaving behind the common strings attached to so-called modern operating systems: bloat, lack of responsiveness and security through obscurity.
Currently, there are nonfree and debug sub repositories for musl but no multilib subrepo.
Generally speaking, a musl based system is a good choice for servers, embedded solutions and old PCs, but it may not be worth the effort to use on a modern desktop computer, due to a couple of serious drawbacks, listed below. In the former cases however, we encourage you to give musl a try.
Some programs (mostly graphical applications) will work incorrectly, or segfault when run under musl. This may be due to programs expecting some glibc-specific behavior. Currently most of breakages are caused by default stack size differences — if you are a software developer, you can try rebuilding musl with a bigger stack size and see if that helps you.
Although musl is arguably the best and fastest libc ever, one can encounter issues using it in conjunction with software which may not be available yet for musl-based systems. The most notable one is usually the lack of proprietary software, which rarely supports other-than-glibc libc implementations, with the exception of bundled stuff like flatpak. Also, some programs that rely on glibc-specific behavior cannot or at least have not been patched yet.
For users of course there are ways around it, the most popular being a glibc chroot.
First, create the directory that will contain your chroot:
$ mkdir ~/void-glibc
Then, install a base system in it:
# xbps-install -S -R https://repo.voidlinux.eu/current -r ~/void-glibc base-voidstrap
Now you make use of your favourite chrooting mechanism.
You will then need to mount the appropriate directories:
# mount --bind ~/void-glibc ~/void-glibc # some programs work incorrectly without this # cp -L /etc/resolv.conf ~/void-glibc/etc/resolv.conf # for network # mount --rbind /proc ~/void-glibc/proc # mount --rbind /sys ~/void-glibc/sys # mount --rbind /dev ~/void-glibc/dev # mount --rbind /run ~/void-glibc/run
Now you can chroot into your new root:
# chroot ~/void-glibc /bin/bash
Inside, you can do practically everything you could outside, plus install and run glibc programs.
If you want to seamlessly use graphical applications, install xhost and run
$ xhost +local:
After automating this process (e.g. by putting the following commands in a script and modifying it to your liking) you can use your chroot for everyday tasks that musl system cannot do yet.
Do not forget to unmount everything after finishing the work!
# umount -Rl ~/void-glibc
From the project's website: "PRoot is a user-space implementation of chroot, mount --bind, and binfmt_misc.".
proot package. Now you can chroot into the glibc environment as any unprivileged user.
# proot -r ~/void-glibc <command>
See the manpage for useful options, for example
-R will bind a useful set of of paths to let the guestfs access information on the host (