Efraim writes: > It turns out the first 2 patches didn't apply cleanly, so I fixed that > up and I'm sending them back to the list. It turns out that git wants to do a full 3-way merge when applying patches, and I formatted the patches from my local repository which has a bunch of extra commits in it that touch gnu/local.mk, so the generated patch referenced a file hash that didn't exist upstream. > A couple of things that I noticed: > > * mono-5.something doesn't have its patches apply cleanly mono-5.10's patches didn't apply cleanly because some of the mono sources being patched used CRLF line endings, and git normalized those in the patch-containing-the-patch. This time around I've tried first running "git config core.autocrlf false", hopefully that fixes it. Note that you'll need to pass '--keep-cr' to 'git am'. > * I was only able to build to mono-3.12 before I got a build failure on > x86_64 After some discussion in #guix we discovered that the cause for this was that parallel builds weren't properly supported. I didn't encounter these failures very much on my own system because I used --keep-failed, which disabled offloading so that they were built on my rather weak 4-core system. I have since tested without --keep-failed and found consistent built failures with '#:parallel-build? #t' all the way up to and including mono-5.10.0, so I've passed '#:parallel-build? #f' to all of those. I have, however, added `"-j" (number->string (parallel-job-count))' to the build-reference-assemblies phase, since that phase takes quite a long time and doesn't seem to have any trouble with parallel builds. > * mono-1.2.6 doesn't have support for aarch64 or riscv64, and will > probably need some patches (later) to add support. Old versions of mono do technically have an interpreter, but by mono-1.2.6 it's already bitrotted to the point of not working (it's not only missing several includes, it also refers to nonexistent fields and procedures that seem to have been since renamed). They eventually fully deleted the interpreter in 2014 in commit 6bee6a7b18978aa6ce977b8b0f9ce19cf962f36b, only to later revive it in 2017 (https://www.mono-project.com/news/2017/11/13/mono-interpreter/). So even if we fixed up mono 1.2.6's interpreter, we'd need to also get it working for each version up to 2017 in order to achieve a fully portable bootstrap path. One alternative option could be some variety of frankenmono: either trying to backport 2017's interpreter to older versions of mono, or trying to run an old mono compiler / class library with a newer mono runtime. Mono's class library depends on runtime-specific icalls, which may have changed over time in a non-backwards-compatible way, which could hinder the latter attempt. The implementation of those icalls, additionally, is probably going to depend on code that is also depended on by the interpreter, so replacing runtime internals to more easily suit the backported interpreter may also require updating those, which could hinder the former attempt. Another possibility would be trying to use pnet's ilrun for mono versions up to 2017, but this would run in to the same issues with runtime-specific icalls, so either mono's class library would need to be adjusted to be able to use pnet's icalls, or mono's icalls would have to be ported to pnet's ilrun, or mcs would have to be adjusted to not depend on anything mono-specific (if it doesn't already). That last possibility may be one of the most interesting, as compilers usually don't need many fancy runtime features (they are after all a very basic batch input-output process that usually solely touches files), and this would effectively strip every intermediate mono build down to just building mcs. Additionally, if the build could be stripped down to just building mcs, we wouldn't need to support the new features used by the class library, which would allow us to make much bigger jumps between versions. The sheer amount of work saved may end up more than making up for ilrun's lower performance. > * libjit FTBFS on powerpc64le. I tried working around it but wasn't > successful in when it came to using libjit. > * The assembly included in libjit targets a too-early version of arm, so > it is just broken completely on armhf and would probably do best with it > being ripped out. libjit is the one component of Portable.NET that outlived its parent project, and it's been updated as recently as 2020. It's supposed to fall back to interpreting on architectures it doesn't support, so it could be that the only changes that need to be made are to refine its detection process. In the meantime, I've adjusted pnet-git to not use libjit on all non-x86 platforms, instead using pnet's own Converted Virtual Machine (CVM) interpreter. This was buggy when using its "unroller" functionality, which requires a small amount of platform-specific code anyway, so I disabled that. This also caused a subtle change in pnetlib-git's test suite, so that a test that previously failed is now properly reported as failing, so I disabled that (it failed due to requiring libx11 and an X server, and due to no provision being made for it to find a .so produced by pnetlib that interfaces with libx11). A V2 series is attached. Note: the full series in one message was rejected by debbugs moderators, but presumably made it through to the other CC'ed recipients. I'm splitting it across some more messages in the hope that it will go through that way. There should be 21 patches in total.