very WIP solo5: 0.6.9 -> 0.7.0

[sternenseemann]

Motivation for this change

Mainly opening this, so we don't duplicate the effort accidentally. My goal is to have pkgsCross.{aarch64,x86_64}-solo5 in the end which just work™ for packages that support it. Specifically, the ocaml compiler in these sets could then automatically switch to ocaml-freestanding and we may even be able to have a proper package sets for MirageOS unikernels…

However, there are currently a few problems:

• Configuring the package set with a consistent platform config seems extremely difficult. solo5 has chosen {aarch64,x86_64}-solo5-none-static as its configuration which we would translate to {aarch64,x86_64}-solo5-none since the link type is stored independently from the platform string for us (Alternatively {aarch64,x86_64}-solo5-none-elf would be more in line with our other "embedded" platforms, however autotools does not like this string at all and I am relatively sure that the embedded configs we pass currently work more by accident). The vendor is enough to throw binutils off and stop it from compiling (I have no clue about gcc as it's not possible to compile without a target libc atm). LLVM swallows the target, but behaves weirdly, insisting on using gcc for linking despite -fuse-ld being passed. Since solo5's toolchain is intended as a bunch of wrapper scripts around a normal linux toolchain you already have, there seems little interest from their side to upstream this into autotools, binutils, LLVM, ... which is annoying, because it means, in order to build the toolchain, we have to configure parts of it with different triples than targetPlatform.config.
  A related problem is that the config string is not configurable in solo5's configure script, so we'll have to patch that in eventually.
• Upstream seems to mostly have tested build == host == target, but supports build == host != target theoretically. The later case is more or less broken with clang however which is the only real option for us atm (it basically ignores that clang is multi target and will never pass -target to it).
• Since this is a wrapper script around a toolchain, we are faced with the choice what to wrap: the wrapped compiler (and reimplement the API / setup hooks of cc-wrapper) or the unwrapped compiler. The latter is the better choice in general (I think at least), but unfortunately quite tricky to implement, because everything mashed together into a single build: solo5 specific bintools, solo5 toolchain wrappers, solo5 runtime libs etc. Untangling this will probably require quite a bit of patching.

These are just a few notes and may be out of date quite quickly when I continue working on this. The current state is quite hacky, but sort of works: the "native" toolchain pkgs.solo5-toolchain works from what I can tell, the cross one pkgsCross.aarch64-solo5 works but chokes on linking which I currently would attribute to some flags getting passed to lld which shouldn't, but I still need to confirm this theory.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[ehmry]

Actually, it would be nice to provide a basic libc for linking with Solo5 unikernels.

[sternenseemann]

Actually, it would be nice to provide a basic libc for linking with Solo5 unikernels.

Upstream was adamant that there is no such thing, but I believe there is a subset of one bundled with ocaml-freestanding. I guess we could we could use that as libc if we're able to untangle the builds sufficiently…

[ehmry]

FWIW I can build Nim programs for Solo5 (without a libc). It's not upstream but obviously I'd like to build services that I can use with NixOS.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/linux-unikernel/22648/2

[sternenseemann]

I want to keep this around since it implements a solo5 cross infra which we still don't have.