For some reason the original source tarball for version 6.1.14 didn't
bundle the sources for `virtio`-support causing a build-failure.
After this was reported, a new tarball named
`VirtualBox-6.1.14a.tar.bz2` was published which fixes the issue[1].
[1] https://www.virtualbox.org/ticket/19862
VirtualBox ships with "alternative BIOS sources" for its virtual BIOS.
These are generated by first compiling the BIOS C sources with the
Open Watcom toolchain, disassembling the output and checking in the
disassembly into the VirtualBox repo.
The result means that the BIOS C code cannot be patched, because it's
not compiled from the C sources, if Open Watcom is not there.
As Open Watcom is now available in nixpkgs, we can just ignore the
alternative BIOS sources and compile it from C directly.
Update Virtualbox to its latest version. This allows compilation against
kernel >= 5.4 to succeed without further patches (see #74260, build
would fail for linux-5.5.5 to 5.5.9).
Newer `iasl`-versions disallow strings within certain declarations[1]
which breaks the virtualbox build as it relies on exactly this
behavior[2].
This should be removed again when updating virtualbox to 6.1.
[1] https://acpica.org/node/172
[2] https://hydra.nixos.org/build/108774352
Quoting from the splitString docstring:
NOTE: this function is not performant and should never be used.
This replaces trivial uses of splitString for splitting version
strings with the (potentially builtin) splitVersion.
These don't use a the virtualbox sources, but an iso as src, and we need
to add the kernel 5.3 patch aswell.
As for some reason the source files are present on the .iso with Windows
Line endings (sic!), call dos2unix first.
Unfortunately, we can't use the same kernel-5.3-fix.patch as virtualbox
itself, as some files are missing and paths are different.
It seems to be broken upstream too, and fixing it is far down the
priority list:
https://www.virtualbox.org/pipermail/vbox-dev/2017-June/014561.html
Additionally, 3d support seems to rely on VBoxOGL.so being symlinked
from libGL.so (which we can't), and Oracle doesn't plan on supporting
libglvnd either. (#18457)
