Musl

From Void Linux Wiki
Jump to: navigation, search

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.

musl use-cases

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.

Possible problems

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.

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.

using chroot

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:

before chrooting.

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

using proot

From the project's website: "PRoot is a user-space implementation of chroot, mount --bind, and binfmt_misc.".

Install the proot package. Now you can chroot into the glibc environment as any unprivileged user.

For example:

 # proot -r ~/void-glibc <command>

See the manpage for useful options, for example -S and -R will bind a useful set of of paths to let the guestfs access information on the host (/tmp/, /dev/, /etc/resolv.conf, ...

External links