add Asahi Linux's muvm for ARM64, including FEX, and libkrun

[RoundDuckKira]

Testing the changes

• I tested the changes in this PR: YES
  The changes work fundlementally, they just are missing driver support for hardware acceleration from the mesa packages.

New package

• This new package conforms to the package requirements: YES

Local build testing

• I built this PR locally for my native architecture, (aarch64)

So here it is, finally the muvm package and associated other packages (FEX by itself would be useful for other ARM64 systems) that allow people like me to run x86_64 programs and packages on ARM platforms like Asahi. It's not 100% polished so take a look around and make suggestions for changes and fixes so I can have this production ready when it gets merged. Also, the two big issues are that there is no RootFS for Void packaged with this, and issue two is that mesa will need asahi support on x86_64 to create a functional RootFS that will support hardware acceleration via drm native context. I have a privately handled RootFS I'm experimenting with, but without the Mesa changes I can't really share it as it won't work well.

[RoundDuckKira]

Also I will soon add steam as an "aarch64" package once the mesa changes come through.

[RoundDuckKira]

currently compiling the aarch64-musl version

[RoundDuckKira]

currently compiling the aarch64-musl version

and yeah it compiles the fucking linux kernel for libkrunfw, wtf 🫩

don't worry it's a requirement for the library

[RoundDuckKira]

Well it doesn't compile on musl due to a build-script hard dependency on glibc... whoops

/usr/bin/ccache /usr/lib/ccache/bin/clang -DARCHITECTURE_arm64=1 -DFEX_HAS_PRESERVE_ALL_ATTR=1 -DFEX_PRESERVE_ALL_ATTR="__attribute__((preserve_all))" -DHAS_PROGRAM_INVOCATION_NAME=1 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_REENTRANT -I/builddir/FEX-2605/build/External/jemalloc_glibc -I/builddir/FEX-2605/External/jemalloc_glibc -I/builddir/FEX-2605/External/jemalloc_glibc/pregen/include -I/builddir/FEX-2605/External/jemalloc_glibc/include -I/builddir/FEX-2605/build/External/jemalloc_glibc/include -DNDEBUG -fstack-clash-protection -D_FORTIFY_SOURCE=2 -march=armv8-a -O2    -ffile-prefix-map=/builddir/FEX-2605/build=. -O3 -DNDEBUG -std=gnu11 -flto=thin -fPIC -fvisibility=hidden -MD -MT External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/malloc_io.c.o -MF External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/malloc_io.c.o.d -o External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/malloc_io.c.o -c /builddir/FEX-2605/External/jemalloc_glibc/src/malloc_io.c
../External/jemalloc_glibc/src/malloc_io.c:100:8: error: incompatible integer to pointer conversion initializing 'char *' with an expression of type 'int' [-Wint-conversion]
  100 |         char *b = strerror_r(err, buf, buflen);
      |               ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
[141/338] Building C object External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/mutex.c.o
[142/338] Building C object External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/ctl.c.o
[143/338] Building C object External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/large.c.o
[144/338] Building C object External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/log.c.o
[145/338] Building C object External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/nstime.c.o
[146/338] Automatic MOC for target FEXConfig
[147/338] Building C object External/jemalloc_glibc/CMakeFiles/FEX_jemalloc_glibc.dir/src/pages.c.o
ninja: build stopped: subcommand failed.
=> ERROR: FEX-2605_1: do_build: '${make_cmd} ${makejobs} ${XBPS_VERBOSE+${make_verbose}} ${make_build_args} ${make_build_target}' exited with 1
=> ERROR:   in do_build() at common/build-style/cmake.sh:102```

[RoundDuckKira]

I apologize for the errors still, I forgot to set my email on the git settings durr

[RoundDuckKira]

Update: the graphics even running ARM programs isn't working, I will have to debug this over time

[RoundDuckKira]

@dkwo @Calandracas606 #55983 I noticed you two have attempted this before, has there been issues with getting this package ready for you guys? Did you guys ever got hardware acceleration working in the microvm?

[RoundDuckKira]

I'm going to close this because I'm going to start a rebase of the pull request, I will link to it when it's ready

[RoundDuckKira]

Well I guess I can't rebase without killing this pull request, so I will do that and start over with a rebase in a few minutes, and I will then mention this closed pull request.

[dkwo]

You can definitely rebase without closing, have a look at the docs.
Also look at prior attempts: that was working fine for me last time I tried (not sure about hardware, I guess I can take a look again once this is in good shape).
For Wayland, at some point I'd like to package https://codeberg.org/drakulix/wl-cross-domain-proxy

[RoundDuckKira]

You can definitely rebase without closing, have a look at the docs. Also look at prior attempts: that was working fine for me last time I tried (not sure about hardware, I guess I can take a look again once this is in good shape). For Wayland, at some point I'd like to package https://codeberg.org/drakulix/wl-cross-domain-proxy

Oh I could do that? Well crap since I just did the close and rebase... it's linked here #61356

But yeah @dkwo sorry about the problem with the pull request stuff, but hey at least the git history is cleaner I suppose. I'm glad at least that now I got venus running, which is a nice second step.