Improve Linux Userlevel Driver Build System

[alexandermbrown]

This issue is referenced partially in both #57 and #63. @wom-bat is currently unable to run the driver VM examples as his version of glibc is different to the one used in the buildroot archive. Since this is a big build system design problem I thought I'd make an issue.

There are two issues with how we build userlevel programs.

1. We currently use zig cc to build these programs. This is all I can currently get working on macOS with Nix but ideally we would only use one compiler (GCC or Clang).

2. Since libraries such as libc and libasound (ALSA) are dynamically linked, we need to ensure we link our userlevel programs to the same version of the shared library as buildroot. This means we cannot simply use the versions installed on the user's OS (by a package manager or Nix) unless we can be sure the user has installed the correct version.

Here are some solution ideas:

• (@wom-bat): in the build step, unpack the library files from the rootfs and link against those (feel free to elaborate or correct me if I'm wrong)
• Put the C files in the rootfs and build them on startup (issue: now we need to pack compilers, make etc.)
• Before (or during) the build step, run an equivalent Linux / rootfs image in Qemu / Docker. Build the user programs and output the binaries. (might be possible with Nix but I'm not sure how)
• Create a custom buildroot package for each userlevel driver (see here). This is idiomatic but also seems like a lot of work. Issue: what if people want to use other distributions.
• (@Ivan-Velickovic): statically link these libraries

I am open to ideas, please let me know if I've got anything wrong.

[Ivan-Velickovic]

Since libraries such as libc and libasound (ALSA) are dynamically linked, we need to ensure we link our userlevel programs to the same version of the shared library as buildroot

Another option would be to only use statically linked versions of all of these.