krein.moe /arvid

Foreign binaries on guix

Recently I have started using guix as the operating system of my computer. While I am quite happy with guix as an OS it brings with it a couple of inconveniences. The worst of these is that just running any binaries you download most of the times does not work. Guix does not use the Filesystem Hierarchy Standard that most other Linux distributions adhere to. This means that binaries looking at /usr/lib/ will not find any libraries there. Also a lot of binaries have a hardcoded linker paths pointing to /lib64/ld-linux-x86-64.so.2 or /lib/ld-linux.so.2.

I respect guix as a from-source distribution. Most programs that I do need I can actually get directly from guix. However, I do like to play video games and a lot of these are, because of their proprietary nature, not able to be packaged in guix.

To get those binaries to run on your guix system there are basically three options:

1. Write a package definition

Nonguix is a project that packages, among others, proprietary software for use in guix. They defined the binary-build-system that is suitable to package binaries you just have but cannot necessarily produce yourself. Packaging for Guix might seem frightening but in the end it's the cleanest and best way to get anything to run. It is just a bit more work than the other methods.

2. Use guix shell with FHS

The command guix shell lets you enter an environment that has a set of defined packages available. Using this command together with the --emulate-fhs option enables you to run programs in an file system that adheres to the Filesystem Hierarchy Standard and looks just like other more ordinary Linux distributions.

I have found it comfortable to collect a list of basic packages that are often assumed to be present by programs. Then I run a guix FHS shell using these packages and execute the binaries. A list of these files can be found here.

To get everything to work with the container method requires some tweaking of shared environment variables and paths. The guix container command uses the -E flag to pass environment variables to the container.

2.1. Variables to pass to guix container

  1. DISPLAY This is so graphical applications know which linux display to use
  2. PULSE_SERVER This is to have sound if you use pulseaudio. You might need to set this variable to pulseaudio's socket path first, as pulseaudio has a default path for it's socket.

2.2. Shared paths that will be useful

  1. $HOME This is good if you have if the program you want to run is in your home directory. I note that I do not use the container to protect my home but to be able to emulate a normal system.
  2. /run/user/<uid> This is where the pulseaudio socket might be
  3. /var/run/dbus/system_bus_socket This is the socket of dbus that some programs expect to be running.

3. Hack with patchelf and LD_LIBRARY_PATH

This one is more of a hack than the previous two. The idea to define a guix environment similar to as described above. But instead of using a guix FHS shell we build the environment to point LD_LIBRARY_PATH to the /lib subpath of it. This takes care of missing library dependencies. To fix the linker issue we use the patchelf --set-interpreter command to rewrite the linker path to the explicit store location of the linker we want to use.

4. Comments

Comment on this post on fedi.