void logo void logo

The Void (Linux) distribution

Void is a general purpose operating system, based on the monolithic Linux® kernel. Its package system allows you to quickly install, update and remove software; software is provided in binary packages or can be built directly from sources with the help of the XBPS source packages collection.

It is available for the Intel x86®, ARM® and MIPS® processor architectures; Software packages can be built natively or cross compiling through the XBPS source packages collection.

Not a fork!

Void Linux is an independent distribution, developed entirely by volunteers.

Unlike trillions of other existing distros, Void is not a modification of an existing distribution. Void's package manager and build system have been written from scratch.

Rolling release

Install once, update daily. Your system will always be up-to-date.

Thanks to our continuous build system, new software is built into binary packages as soon as the changes are pushed to the void-packages repository.


We use runit as the init system and service supervisor.

runit is a simple and effective approach to initialize the system with reliable service supervision. See the usage page for a brief introduction.


We were the first distribution to switch to LibreSSL by default, replacing OpenSSL.

Due to the Heartbleed fiasco we believe that the OpenBSD project has qualified and pro-active developers to provide a more secure alternative.


xbps is the native system package manager, written from scratch with a 2-clause BSD license.

xbps allows you to quickly install/update/remove software in your system and features detection of incompatible shared libraries and dependencies while updating or removing packages (among others). See the usage page for a brief introduction.


xbps-src is the xbps package builder, written from scratch with a 2-clause BSD license.

This builds the software in containers through the use of Linux namespaces, providing isolation of processes and bind mounts (among others). No root required!

Additionally xbps-src can build natively or cross compile for the target machine, and supports multiple C libraries (glibc and musl currently).

void-packages changes

xbps changes

February 12, 2019

VoidLinux.eu Is Not Ours

We would like to warn people of a domain name that is no longer under Void Linux control. voidlinux.eu lapsed in its original registration, and was purchased by an unknown 3rd party before Void Linux could regain ownership. At this time, please assume that anything involving voidlinux.eu is not related to Void Linux, and should be considered potentially malicious. Of course, if the person who owns the domain now would like to transfer it to our control, we’d be grateful, and will update voidlinux.org to indicate if this happens.

Our official domain is VoidLinux.org.

February 03, 2019

Cross compilation support for gobject typelibs

Thanks to the work of maxice8 we’re pleased to announce cross compiling support for gobject-introspection and packages that depend on this tool. This is a big step forward to support more packages through cross compiling and stay future proof for glib development.

maxice8 put together a comprehensive post about his work. This article will be higher level overview of our work in this field.

What are gobject and typelibs?

gobject is an abstract description of types defined in glib. Glib is used on a wide range of application and libraries, most notably gtk. Glib itself is written in C but it’s possible to provide dynamic language bindings to other languages such as python.

This mechanism is not builtin into glib, but instead is provided by the gobject-introspection tool. This tool scans both the source and the binary blob of a library and creates a metadata file that is used to provide type information for other language bindings. For a deeper dive into gobject-introspection please consider the docs at readthedocs.io

The problem

When it comes to Void, we have high demands on portability of applications. Our armv6l, armv7l and aarch64 platforms a completely and exclusively cross compiled, meaning they are built on an x86_64 host. This leads to an interesting problem with gobject-introspection which by design needs to run on the same platform as the produced binaries are targeted.

Unfortunately, as already stated this has been a design decision of this software and we can’t do anything to change this constraint itself.

Furthermore, during the last few years the Gnome community drifted towards extensively using gobject-introspection in their products. This led to the breakage of more and more applications in the gnome-ecosystem.

The solution

During the last few months we considered different solutions to this problem. This first proposal to not support gir through cross compilation and only allow it through native build became more and more unsatisfying as the number of packages using this mechanism increased over time.

The second approach which was the followup to the one described above was to add native builders to the system and build those packages on those native builders. The issue was here that this would require a lot of infrastructure work and added a lot of complexity.

The third solution and the one we chose was to use the userspace emulation features of Qemu to emulate the target system only for those calls that needed to be on the target platform. The yocto project is already using this approach to cross compile Gnome Applications to other platform. We reused many of their tooling for void-packages. Nontheless, we hit many porting issues - our tooling must run on musl, too - , new bugs were triggered in void-packages - see for example these two posts at maxice8’s blog, and many other small issues needed to be resolved.

Basic support for cross compilation has already landed in void-packages, the musl port is not yet finished, but we expect it to work soon(tm).

maxice8 also prepared a blog post about his porting work on libgusb.