GNU bug report logs - #74609
[PATCH] Adding a fully-bootstrapped mono

Previous Next

Full log

View this message in rfc822 format

From: unmush <unmush <at> proton.me>
To: "74609 <at> debbugs.gnu.org" <74609 <at> debbugs.gnu.org>
Subject: [bug#74609] V2 series
Date: Fri, 20 Dec 2024 05:12:29 +0000

[Message part 1 (text/plain, inline)]

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.

[v2-0001-gnu-add-treecc.patch (text/x-patch, attachment)]

[v2-0003-gnu-Add-pnetlib-git.patch (text/x-patch, attachment)]

[v2-0002-gnu-Add-pnet-git.patch (text/x-patch, attachment)]

[v2-0007-gnu-Add-mono-2.6.4.patch (text/x-patch, attachment)]

[v2-0004-gnu-Add-mono-1.2.6.patch (text/x-patch, attachment)]

[v2-0006-gnu-Add-mono-2.4.2.patch (text/x-patch, attachment)]

[v2-0005-gnu-Add-mono-1.9.1.patch (text/x-patch, attachment)]

[v2-0009-gnu-Add-mono-3.0.patch (text/x-patch, attachment)]

[v2-0010-gnu-Add-mono-3.12.1.patch (text/x-patch, attachment)]

[v2-0008-gnu-Add-mono-2.11.4.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.