[PATCH] Adding a fully-bootstrapped mono

We used to have a mono package, but it was removed due to includingbootstrap binaries (among others).  This patch series introduces a full,

17-mono-package sequence that takes us from a mono-1.2.6 built fully

from source to mono-6.12.0 built fully from source, using only packages

that already have full bootstrap paths.  I make no promise that this is

the shortest or most optimal path, but it exists and I have verified it

works.

As I've spent what is probably an unreasonable amount of time working

toward this, I thought I'd share some of my thoughts, experiences, and

commentary.  Sorry in advance if it gets a bit rambly or lecture-ish.

I started down this road because someone I'm working on a project with

decided to depend on a C# package that requires C# 12.0 features, and my

personal mono package based on the tarball releases (which include

bootstrap binaries) only went up to C# 7.0.  This meant that the C#

package in question de facto required strictly Microsoft's (er, I mean,

"the .NET foundation"'s) .NET implementation - hereafter referred to as

"dotnet" - and a very recent version no less.  The bootstrapping story

with dotnet is very bad:

https://github.com/dotnet/source-build/issues/1930. Even beginning to

untangle it would probably require a relatively modern C# compiler, and

something that at least sort of understands msbuild.  And there's not

much point to "bootstrapping" dotnet from something that isn't

bootstrapped itself.  So I figured I may as well start with mono.

While mono is today probably the most well-known alternative to

Microsoft's .NET offerings, it is not the only one.  Indeed, in the

early 2000s there were at least 2 competing free software

implementations: Mono, and DotGNU's Portable.NET (abbreviated pnet).

They differed in goals, licenses, and methods: Portable.NET was a GNU

project concerned with, among other things, limiting the ability of

Microsoft to impose vendor lock-in via its proprietary .NET

implementation and software patents.  As a GNU project, it used the GPL

for its runtime and compiler, and the GPL with a linking exception for

its standard library, pnetlib.  Mono, on the other hand, used a mix of

many copyleft and permissive licenses: X11 for the standard library, GPL

for the compiler (later dual-licensed to add an X11 option), and LGPL

for the runtime, with GPL and LGPL code also offered "under commercial

terms for when the GPL and the LGPL are not suitable".  In 2016 after

its acquisition by Microsoft, the runtime was relicensed to use the

Expat (MIT) license.

But perhaps most importantly to us, while Mono opted to write its C#

compiler, mcs, in... C#, Portable.NET's runtime and C# compiler were

both written in C.  Portable.NET along with the entire DotGNU project

was decommissioned in 2012, but the source is still available, and it

still works fine (with a few modifications for compatibility with newer

versions of its dependencies).  In https://issues.guix.gnu.org/57625

Adam Faiz submitted patches to package pnet and pnetlib, along with one

of their dependencies named treecc.  These packages were based on the

last release of Portable.NET, version 0.8.0, released in 2007.  I

initially used these packages as the basis for my bootstrap efforts, and

even managed to get mono-1.2.6 built using them, but later discovered

that using a more recent version from git made it much easier.  For

example, while pnet-0.8.0 can do pointer arithmetic inside unsafe code

blocks, it doesn't support the += or -= operators specifically, which

requires lots of patching (after all, who would use x = x + y when you

could do x+= y?).  There are many other similar improvements in the git

version, so for this patch series I've decided to go with pnet-git.

After building mono-1.2.6, I tried a few later versions, and the third

or fourth one would always fail with errors about missing methods.  It

turns out that the reason for this is that, contrary to what their

marketing suggests, C# and Java are not "write once, run everywhere".

This is because their compilers rely on the details of the libraries

that the program will be run with at compile-time.  This is used, for

example, to do overload resolution.  Suppose, for example, that a

certain implementation of the "==" operator is present in version 1.0 of

a library, and then in version 2.0 of a library a more specific

implementation is introduced.  Now code that is compiled against version

2.0 may instead automatically reference the more-specific

implementation, as is in accordance with the rules of C#.  But when it

is run with version 1.0, it will fail because that implementation

doesn't exist.  In my case, for some reason the initial mcs and core

libraries being built to compile the rest of mono were being compiled

against a 2.0 library and then run with a 1.0 library.  It turns out

that this was because mcs uses mono's code for producing assemblies

(.NET dlls and exes), and mono decides which version to put in an

assembly it writes based on "which runtime version" is being used, and

that version is decided at startup based on... the version that was put

in the assembly it is running.  So for example, mono-1.9.1 would produce

2.0 assemblies because mono-1.2.6 produced 2.0 assemblies because pnet

produced 2.0 assemblies.  So I modified mono's runtime in mono-1.9.1 to

allow for this version to be overridden via environment variable, and

set it to "v1.1.4322", and things went a lot more smoothly after that.

From there on it was mostly the usual trial-and-error process of

identifying where things had bitrotted.  I made sure to unvendor libgc

wherever possible, though eventually by mono-4.9.0 they explicitly

dropped support in their configure script for using any libgc other than

what was bundled, so at that point I switched to using their homebrewed

sgen garbage collector.

Once I got to mono-2.11.4, though, things took a turn for the

interesting: mono started using git submodules, and the (recursive? #t)

clones were all failing.  It turns out that this is because their

submodules reference github.com using the git:// protocol.

This is notable for a few reasons.

First, github dropped support for the git:// protocol in 2021, so

recursive clones won't work now.  This means I have to explicitly list

out every submodule, its commit, and its sha256 hash, for every mono

version until they switched to using http or https.  mono-2.11.4 has

only 4 submodules, but that doesn't last for long: by mono-4.9.0 it has

14 submodules.  A significant portion of these patches is just listing

these submodules and their hashes.  It's a bit annoying.

The more concerning reason, though, is *why* github dropped support for

the git:// protocol: it is unencrypted and unauthenticated.  This is

mitigated somewhat by the use of sha-1 hashes to identify commits in the

referenced submodules, putting a significant computational burden on

anyone who would try to alter what was fetched corresponding to a given

submodule.  Significantly more risky, though, is the process of

*updating* submodules that use git:// URLs.  It is quite unlikely that a

developer is going to independently clone one of the submodules over

https, navigate to a desirable commit, copy the sha-1 hash, and manually

update the submodule reference's commit.  They're far more likely to run

'cd submodule; git pull; cd ..; git add submodule; git commit ...' or an

equivalent.

Of course, any changes a network man-in-the-middle might try to make

here would still be reflected in the commit history, so even if a

developer did that, they or any of their fellow committers could spot

anything strange or malicious and point it out.  Also, the changes

couldn't be propagated to others trying to pull them who weren't on a

path containing the MITM because the potentially-malicious commit

wouldn't be present in the real submodule's repository.  So the

transparency of git clearly showing changes to text files, combined with

the fact that surely no git hosting platform would just allow arbitrary

entities to make whatever commits they want accessible under any

arbitrary repository URL, rather mitigate this security issue.

This usage of git:// URLs lasted all the way until September 28, 2021,

when github's removal of support for it forced the developers to change

them to https.

On November 28, 2016, mono added a submodule named roslyn-binaries.

Unsurprisingly, it included binary blobs for Microsoft's Roslyn compiler

(which I believe had been open-sourced shortly prior).  From here on,

mono's build system would default to using these binaries for building

on little-endian systems (though another compiler could be specified

with the --with-csc configure flag).  I happen to know that it is

extremely unlikely that many mono developers used this configure flag.

I know this because the 5.0 series is an absolute pain in the neck to

build from source, because they consistently depend on new C# features

*before* they implement them.

To go on a brief tangent: does anyone remember back when youtube-dl was

temporarily taken down from github due to the RIAA's DMCA request?  Many

were unhappy about that.  One such unhappy person made news when they

made the full contents of youtube-dl's repository available to access

through the DMCA request repository:

https://gist.github.com/lrvick/02088ee5466ca51116bdaf1e709ddd7c. It

turns out that there are many actions that one can take on github that

will make arbitrary commits available under arbitrary repository URLs.

So, in reality, for the span of time from November 28, 2016 to

September 28, 2021, anybody sitting on the network path between github

and any mono developer updating the roslyn-binaries submodule could

decide on any arbitrary new commit to be used.  Of course, merely

inspecting the diff for the commit will reveal nothing of use, because

the contents are binary blobs.  And not only are these blobs those of a

compiler, they are the blobs of a compiler that is sure to be used to

compile another compiler, which will then be redistributed as an opaque,

non-bootstrappable binary blob to be used for compiling other compilers.

You would be hard-pressed to find a more fertile breeding ground for Ken

Thompson / Trusting Trust attacks.  If every agent of the NSA (and

whatever other agencies, including those of other countries, had access

to the appropriate network traffic) somehow failed to capitalize on 6

years of opportunity to compromise an entire software ecosystem using

only a basic MITM of unencrypted traffic, they deserve to be sacked.

Whether such an attack actually occurred or not, this is a case study in

carelessness and why bootstrappability is so important; discovering all

this made me quite worried about having used a mono version built from

blobs previously, and has convinced me that, as time-wasting and tedious

as this project has been, it is nevertheless probably an important one.

If you're going to write a self-hosting compiler, the least you can do

is keep it self-hosting.  Deciding to write a self-hosting compiler is a

valid choice, of course, with its own merits and demerits, but there is

something bitterly poetic about mono starting out requiring specifically

Microsoft's C# compiler in order to build (mono did its initial

bootstrapping using Microsoft's proprietary csc), achieving independence

through self-hosting, being acquired by Microsoft, and thereafter coming

crawling back to Microsoft's C# compiler once more before eventually

dying.

The funny thing is that it's not even necessary.  The dependencies on

new C# features are all in mono's standard library (which increasingly

borrowed code from Microsoft's corefx library), not in mono's compiler.

Even before roslyn-binaries, there was binary-reference-assemblies,

which contained prebuilt "reference" blobs for the various versions of

the standard libraries.  These exist, I assume, precisely because of the

library incompatibility problems regarding overloading that I mentioned

earlier.  While later versions of mono included sources and a build

system for producing these reference binaries, mono-4.9.0 and earlier

did not.  Mono's build system still demanded /something/ to install,

though, so I told it to use the real standard library of the input mono

version.  When I did get to a mono version that at least claimed to

support regenerating the reference binaries, I found that it didn't work

with mcs due to differences in which libraries had to be referenced, so

I had to patch it to add a bunch of references determined through trial

and error.

The xunit-binaries submodule was also added sometime before mono-5.1.0.

This dependency makes it impossible to run the full test suite without

binary blobs.  Presumably for this reason, Debian elects to only run

tests within the mono/mini/ and mono/tests/ subdirectories.  For my

part, I've disabled all tests except for those of mono-6.12.0, the final

version, limited to the two aforementioned subdirectories.  This is

because it would take extra time for the builds, because several of the

tests depend on binary blobs bundled into the mono repository itself

(which my thorough cleaning of all dlls and exes from the sources

removes), because a large chunk of the tests depend on binary blobs in

xunit-binaries in later versions, and because "expect some test

failures" is part of the mono documentation and I don't have the

time to figure out for the mono developers every reason why each of 17

versions of their test suite is broken.

The 5.0 series was when Microsoft acquired Mono, and it shows.  You'll

notice I needed to introduce "pre-" packages for various versions

because in several cases a tagged release could not build the following

tagged release.  For that matter, they couldn't build the pre- package

either, but it at least took fewer patches to get them working.  The

reason for this is that Mono added a dependency on Microsoft's corefx

library source code, and it usually started using C# features well

before mcs was able to compile them.  Because of this, despite taking 8

versions to get from 1.2.6 to 4.9.0, it took another 8 versions to get

through the 5.0 series, and 5 of them required nontrivial patching to

massage the source into a form compilable by mcs.

Eventually I realized that the dependencies on new features were all

coming from corefx, not from mono's compiler.  Consequently, the only

reason for this particular bootstrap-hostile ordering of builds is that

it happened to be the order the mono devs committed things.  So I just

cherry-picked every commit I could find touching mcs/mcs (magit was

quite useful for this) and applied it to 5.10.0 to produce what is

essentially the 6.12.0 compiler, then used it to jump straight to

building 6.12.0.

Use of this technique earlier on in the bootstrap process may be

of interest to anyone looking to shorten the chain of packages.

My initial goal was to package dotnet, and I had tried to progress

toward that from mono-4.9.0 for a period, but with no success.  During

that time, though, I did encounter a bug in mono's xbuild condition

parser, which I wrote a patch for, and included in mono-6.12.0.

I also discovered that xbuild would wrongly complain about missing

references even when the proper assemblies were in MONO_PATH or

MONO_GAC_PREFIX, because xbuild would erroneously only consider the path

/gnu/store/...mono-6.12.0/lib/mono/gac when looking for global assembly

caches, completely ignoring MONO_GAC_PREFIX.  So I wrote a patch to fix

that, and included it in mono-6.12.0.

Having witnessed how much nicer it is to package things that use rpath /

runpath than things that use environment variables (like python) and

therefore require constant wrapping of executables and use of

propagated-inputs, I devised a patch that would extend mono's

per-assembly config files to support a <runpath> element.  For example,

if you have a file /tmp/dir2/test2.exe, and there is also a file

/tmp/dir2/test2.exe.config, and its contents are

<?xml version="1.0" encoding="utf-8"?>

<configuration>

  <runpath path="/tmp/dir1"/>

</configuration>

and it references test1.dll, it will first look for it at

/tmp/dir1/test1.dll.  Note that, of course, test1.dll still needs to be

accessible to the compiler at compile-time through MONO_PATH or an

explicitly-specified path passed on the mcs command line.

It is my hope that this feature will be of use to anybody interested in

developing a build system.

Mono had several difficult points in bootstrapping and packaging, but at

the end of the day it still met the basic description of a software

package: well-defined environment-supplied inputs and sources, a

user-supplied install prefix, and files installed under that prefix.

The dotnet world is an entirely different beast.  The first step of most

build systems I have encountered from that realm is downloading an

entire toolchain, among other dependencies, as a binary blob.  They

heavily depend on the exact packages they specify being available

exactly where they say to install them.  There is no "install", there

are no "install directories" to my knowledge.  A build that doesn't

contact nuget.org is an abberation.  I am at a loss how to build these

things, much less package them.  I badly need help.

"You wish now that our places had been exchanged.  That I had died, and

DotGNU had lived?"

"... Yes.  I wish that."

Maintenance of Mono was recently transferred over to WineHQ.  With that

announcement this statement was placed at https://www.mono-project.com:

"We want to recognize that the Mono Project was the first .NET

implementation on Android, iOS, Linux, and other operating systems. The

Mono Project was a trailblazer for the .NET platform across many

operating systems. It helped make cross-platform .NET a reality and

enabled .NET in many new places and we appreciate the work of those who

came before us."

I would like to clarify that, according to Miguel de Icaza himself

(https://www.mono-project.com/archived/mailpostearlystory/),DotGNU

"started working on the system about the same time".  According to

https://lwn.net/2002/0103/a/dotgnu.php3Portable.NET began "in January

2001".  While it's unclear exactly when Portable.NET reached various

milestones, and the significance of the various milestones varies

somewhat (for example, mono probably does not care that Portable.NET

also includes a Java and C compiler), I think that there is cause to

dispute the claim that Mono was "the first" .NET implementation on

Linux.

On a related note, if we haven't looked at the possibility of using

Portable.NET in the Java bootstrap process, it may be worth visiting at

some point.

Thank you for your time, I think I need to get some rest now.

- unmush

Thank you for this unmush, that is quite the achievement. The whole C# and

dotnet tooling flabbergasts me, but this definitely could help. I was a bit

disappointed with the previous removal (but totally understand), hopefully

this can be merged in as there are a few nice programs that are written in

C# (but they also require dotnet...).

v/r,

Aaron

Congratulations on the achievement! I want to thank you for your

writeup. I found it very interesting!

--

Take it easy,

Richard Sent

Making my computer weirder one commit at a time.

Hi,

unmush <unmush@proton.me> skribis:

I join others in congratulating you! This is very impressive, and a

great step forward.

I’ll make time to review and apply those patches if nobody beats me at it.

Thank you!

Ludo’.

Ludovic Courtès writes:

+1

Impressive, thank you!

Greetings,

Janneke

--

Janneke Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond https://LilyPond.org

Freelance IT https://www.JoyOfSource.com| Avatar® https://AvatarAcademy.com

unmush <unmush@proton.me> skribis:

As I read this, I realize that ‘git-fetch-with-fallback’ (used by

‘git-fetch’ for origins) won’t actually fall back to Software Heritage

for just submodules. It’s all or nothing.

So the SWH fallback didn’t help you at all, right?

In an ideal world, it would have kicked in automatically.

Ludo’.

(treecc): New variable.

Change-Id: If3f36615774c872f3015510eb08ec53657e4edfb

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 62 +++++++++++++++++++++++++++++++++++++++++

2 files changed, 63 insertions(+)

create mode 100644 gnu/packages/dotnet.scm

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.

A couple of things that I noticed:

x86_64

probably need some patches (later) to add support.

successful in when it came to using libjit.

it is just broken completely on armhf and would probably do best with it

being ripped out.

unmush (21):

gnu: Add treecc.

gnu: Add pnet-git.

gnu: Add pnetlib-git.

gnu: Add mono-1.2.6.

gnu: Add mono-1.9.1.

gnu: Add mono-2.4.2.

gnu: Add mono-2.6.4.

gnu: Add mono-2.11.4.

gnu: Add mono-3.0.

gnu: Add mono-3.12.1.

gnu: Add mono-4.9.0.

gnu: Add mono-5.0.1.

gnu: Add mono-5.1.0.

gnu: Add mono-5.2.0.

gnu: Add mono-5.4.0.

gnu: Add mono-pre-5.8.0.

gnu: Add mono-5.8.0.

gnu: Add mono-pre-5.10.0.

gnu: Add mono-5.10.0.

gnu: Add libgdiplus.

gnu: Add mono-6.12.0.

gnu/local.mk | 21 +

gnu/packages/dotnet.scm | 1830 +++++++

.../patches/corefx-mono-5.4.0-patches.patch | 915 ++++

.../corefx-mono-pre-5.8.0-patches.patch | 1349 +++++

.../patches/mono-1.2.6-bootstrap.patch | 585 +++

...-1.9.1-add-MONO_CREATE_IMAGE_VERSION.patch | 14 +

gnu/packages/patches/mono-1.9.1-fixes.patch | 59 +

gnu/packages/patches/mono-2.11.4-fixes.patch | 36 +

gnu/packages/patches/mono-2.4.2.3-fixes.patch | 59 +

gnu/packages/patches/mono-2.6.4-fixes.patch | 49 +

...ono-4.9.0-fix-runtimemetadataversion.patch | 13 +

.../mono-5.10.0-later-mcs-changes.patch | 4601 +++++++++++++++++

gnu/packages/patches/mono-5.4.0-patches.patch | 100 +

gnu/packages/patches/mono-5.8.0-patches.patch | 60 +

.../patches/mono-6.12.0-add-runpath.patch | 185 +

.../mono-6.12.0-fix-AssemblyResolver.patch | 236 +

.../mono-6.12.0-fix-ConditionParser.patch | 46 +

.../mono-mcs-patches-from-5.10.0.patch | 4218 +++++++++++++++

.../patches/pnet-fix-line-number-info.patch | 13 +

.../patches/pnet-fix-off-by-one.patch | 13 +

.../patches/pnet-newer-libgc-fix.patch | 45 +

.../patches/pnet-newer-texinfo-fix.patch | 13 +

22 files changed, 14460 insertions(+)

create mode 100644 gnu/packages/dotnet.scm

create mode 100644 gnu/packages/patches/corefx-mono-5.4.0-patches.patch

create mode 100644 gnu/packages/patches/corefx-mono-pre-5.8.0-patches.patch

create mode 100644 gnu/packages/patches/mono-1.2.6-bootstrap.patch

create mode 100644 gnu/packages/patches/mono-1.9.1-add-MONO_CREATE_IMAGE_VERSION.patch

create mode 100644 gnu/packages/patches/mono-1.9.1-fixes.patch

create mode 100644 gnu/packages/patches/mono-2.11.4-fixes.patch

create mode 100644 gnu/packages/patches/mono-2.4.2.3-fixes.patch

create mode 100644 gnu/packages/patches/mono-2.6.4-fixes.patch

create mode 100644 gnu/packages/patches/mono-4.9.0-fix-runtimemetadataversion.patch

create mode 100644 gnu/packages/patches/mono-5.10.0-later-mcs-changes.patch

create mode 100644 gnu/packages/patches/mono-5.4.0-patches.patch

create mode 100644 gnu/packages/patches/mono-5.8.0-patches.patch

create mode 100644 gnu/packages/patches/mono-6.12.0-add-runpath.patch

create mode 100644 gnu/packages/patches/mono-6.12.0-fix-AssemblyResolver.patch

create mode 100644 gnu/packages/patches/mono-6.12.0-fix-ConditionParser.patch

create mode 100644 gnu/packages/patches/mono-mcs-patches-from-5.10.0.patch

create mode 100644 gnu/packages/patches/pnet-fix-line-number-info.patch

create mode 100644 gnu/packages/patches/pnet-fix-off-by-one.patch

create mode 100644 gnu/packages/patches/pnet-newer-libgc-fix.patch

create mode 100644 gnu/packages/patches/pnet-newer-texinfo-fix.patch

base-commit: 6774c9e75a835e91e9b0e415c749e48e4f724e24

--

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

New patch.

Change-Id: I19c16041fa4419a7c31ca510da6f33a03785f584

---

gnu/local.mk | 2 +

gnu/packages/dotnet.scm | 60 +++++++++++++++++++

...-1.9.1-add-MONO_CREATE_IMAGE_VERSION.patch | 14 +++++

gnu/packages/patches/mono-1.9.1-fixes.patch | 59 ++++++++++++++++++

4 files changed, 135 insertions(+)

create mode 100644 gnu/packages/patches/mono-1.9.1-add-MONO_CREATE_IMAGE_VERSION.patch

create mode 100644 gnu/packages/patches/mono-1.9.1-fixes.patch

Change-Id: I751e97088e2b848078889b2033ebb4356d3cfe4b

---

gnu/local.mk | 4 +

gnu/packages/dotnet.scm | 99 +++++++++++++++++++

.../patches/pnet-fix-line-number-info.patch | 13 +++

.../patches/pnet-fix-off-by-one.patch | 13 +++

.../patches/pnet-newer-libgc-fix.patch | 45 +++++++++

.../patches/pnet-newer-texinfo-fix.patch | 13 +++

6 files changed, 187 insertions(+)

create mode 100644 gnu/packages/patches/pnet-fix-line-number-info.patch

create mode 100644 gnu/packages/patches/pnet-fix-off-by-one.patch

create mode 100644 gnu/packages/patches/pnet-newer-libgc-fix.patch

create mode 100644 gnu/packages/patches/pnet-newer-texinfo-fix.patch

Change-Id: I3a041de181d96bfe9e447d72ddd9578e12db8014

---

gnu/packages/dotnet.scm | 57 +++++++++++++++++++++++++++++++++++++++++

1 file changed, 57 insertions(+)

Change-Id: I73765d921c28c473271a2038dfaa53cc7fdad3c5

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 145 +++++

.../patches/mono-1.2.6-bootstrap.patch | 585 ++++++++++++++++++

3 files changed, 731 insertions(+)

create mode 100644 gnu/packages/patches/mono-1.2.6-bootstrap.patch

Change-Id: I14ff01d5fb3c3f23c83f8518990a79329490d3b9

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 53 +++++++++++++++++

gnu/packages/patches/mono-2.4.2.3-fixes.patch | 59 +++++++++++++++++++

3 files changed, 113 insertions(+)

create mode 100644 gnu/packages/patches/mono-2.4.2.3-fixes.patch

Change-Id: I66e9bb2e12ca6f47b4cd827822db5bee93b64dfe

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 23 ++++++++++

gnu/packages/patches/mono-2.6.4-fixes.patch | 49 +++++++++++++++++++++

3 files changed, 73 insertions(+)

create mode 100644 gnu/packages/patches/mono-2.6.4-fixes.patch

(mono-3.12.1-external-repo-specs, mono-3.12.1): New variables.

Change-Id: Id5d13492163aabb845c47609f52287c5565497a4

---

gnu/packages/dotnet.scm | 52 +++++++++++++++++++++++++++++++++++++++++

1 file changed, 52 insertions(+)

(mono-2.11.4-external-repo-specs, mono-2.11.4): New variables.

(add-external-repos): New procedure.

Change-Id: I7cb96af8b05a625cfe9ca9ab0f1132608c02ed31

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 95 ++++++++++++++++++++

gnu/packages/patches/mono-2.11.4-fixes.patch | 36 ++++++++

3 files changed, 132 insertions(+)

create mode 100644 gnu/packages/patches/mono-2.11.4-fixes.patch

Change-Id: Iea5926e79f7877aca718c1312c89bcc715b64d21

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 129 ++++++++++++++++++

...ono-4.9.0-fix-runtimemetadataversion.patch | 13 ++

3 files changed, 143 insertions(+)

create mode 100644 gnu/packages/patches/mono-4.9.0-fix-runtimemetadataversion.patch

(mono-3.0.12-external-repo-specs, mono-3.0): New variables.

Change-Id: I1f30041187c7d0cf6e45d56f6da9bb4a705202cf

---

gnu/packages/dotnet.scm | 63 +++++++++++++++++++++++++++++++++++++++++

1 file changed, 63 insertions(+)

(mono-5.0.1-external-repo-specs, mono-5.0.1): New variables.

Change-Id: I165ef8238c4adddcf92667c34dbb366f98d288bd

---

gnu/packages/dotnet.scm | 133 ++++++++++++++++++++++++++++++++++++++++

1 file changed, 133 insertions(+)

(mono-5.1.0-external-repo-specs, mono-5.1.0): New variables.

Change-Id: Ie58e20f75920ee0492e977c82a2e302311793946

---

gnu/packages/dotnet.scm | 68 +++++++++++++++++++++++++++++++++++++++++

1 file changed, 68 insertions(+)

(mono-5.2.0-external-repo-specs, mono-5.2.0): New variables.

Change-Id: I089850bfd50f229af5a236bbc39ee9ae4787ef9f

---

gnu/packages/dotnet.scm | 67 +++++++++++++++++++++++++++++++++++++++++

1 file changed, 67 insertions(+)

(mono-pre-5.8.0-external-repo-specs, mono-pre-5.8.0): New variable.

Change-Id: Id573b051e01980867a07032f339fdb2829b2a413

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 79 +

.../corefx-mono-pre-5.8.0-patches.patch | 1349 +++++++++++++++++

3 files changed, 1429 insertions(+)

create mode 100644 gnu/packages/patches/corefx-mono-pre-5.8.0-patches.patch

(mono-5.4.0-external-repo-specs, mono-5.4.0): New variables.

Change-Id: I1510c8ac13db60e5beab8033be3efc483e984ec0

---

gnu/local.mk | 2 +

gnu/packages/dotnet.scm | 92 ++

.../patches/corefx-mono-5.4.0-patches.patch | 915 ++++++++++++++++++

gnu/packages/patches/mono-5.4.0-patches.patch | 100 ++

4 files changed, 1109 insertions(+)

create mode 100644 gnu/packages/patches/corefx-mono-5.4.0-patches.patch

create mode 100644 gnu/packages/patches/mono-5.4.0-patches.patch

(mono-5.8.0-external-repo-specs, mono-5.8.0): New variables.

Change-Id: Iea71bf52d67a182f7543adaba44409dbf6c3c0e2

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 123 ++++++++++++++++++

gnu/packages/patches/mono-5.8.0-patches.patch | 60 +++++++++

3 files changed, 184 insertions(+)

create mode 100644 gnu/packages/patches/mono-5.8.0-patches.patch

(mono-5.10.0-external-repo-specs, mono-5.10.0): New variables.

Change-Id: Ic5e123c2cd12f9b77d012cd7d73f9be0b5a608ec

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 119 +

.../mono-5.10.0-later-mcs-changes.patch | 4601 +++++++++++++++++

3 files changed, 4721 insertions(+)

create mode 100644 gnu/packages/patches/mono-5.10.0-later-mcs-changes.patch

(mono-pre-5.10.0-external-repo-specs, mono-pre-5.10.0): New variables.

Change-Id: Ie78dce071032b6743b6e4c2eb58e43bc89e6a1d1

---

gnu/local.mk | 1 +

gnu/packages/dotnet.scm | 73 +

.../mono-mcs-patches-from-5.10.0.patch | 4218 +++++++++++++++++

3 files changed, 4292 insertions(+)

create mode 100644 gnu/packages/patches/mono-mcs-patches-from-5.10.0.patch

Change-Id: I492254c09fd6c9c8b0bc633e1f95665bfa9fe96a

---

gnu/packages/dotnet.scm | 44 +++++++++++++++++++++++++++++++++++++++++

1 file changed, 44 insertions(+)

This includes a patch to add support for a <runpath> element to

mono's *.dll.config and *.exe.config files. See mono-6.12.0-add-runpath.patch

for details.

(mono-6.12.0-external-repo-specs, mono-6.12.0): New variable.

Change-Id: I9d5bd5d366c368eb235483411818c90374bfc4d4

---

gnu/local.mk | 3 +

gnu/packages/dotnet.scm | 194 ++++++++++++++

.../patches/mono-6.12.0-add-runpath.patch | 185 ++++++++++++++

.../mono-6.12.0-fix-AssemblyResolver.patch | 236 ++++++++++++++++++

.../mono-6.12.0-fix-ConditionParser.patch | 46 ++++

5 files changed, 664 insertions(+)

create mode 100644 gnu/packages/patches/mono-6.12.0-add-runpath.patch

create mode 100644 gnu/packages/patches/mono-6.12.0-fix-AssemblyResolver.patch

create mode 100644 gnu/packages/patches/mono-6.12.0-fix-ConditionParser.patch

merge 57625 74609

thankyou

Efraim writes:

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.

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'.

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.

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 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.