Cannot build without binary-reference-assemblies

[directhex]

Linux distributions with strict policies regarding from-source distribution can generally let bootstrap binaries (i.e. Monolite) fly, but don't allow random binaries with unknown, undocumented history.

If we're treating the entirety of binary-reference-assemblies as bootstrap binaries (:grimacing:) then we should be regenerating the entire tree from source during the build and using the replacements. If we aren't, then we should (at least optionally?) avoid using them during the build, and make them optional.

Random binaries are bad, hence the existence of https://github.com/dotnet/source-build

[marek-safar]

They are not random they have full sources and Makefile includes but we treat them as a precompiled version to simplify and speed up build.

We could introduce full rebuild as part of the build where the outcome is exactly same binaries at the same place

[directhex]

They are not random they have full sources and Makefile includes but we treat them as a precompiled version to simplify and speed up build.

I understand the desire to keep things cached & fast

We could introduce full rebuild as part of the build where the outcome is exactly same binaries at the same place

Even if it were optional, this would greatly help distribution packagers - especially to avoid make install copying prebuilt assemblies. Basically, the goal is for everything make install installs to have been built by make; everything make needs in order to build should be rebuildable as part of make

[akoeplinger]

This should be relatively easy to do. Remove all the .dll's in the submodule from the tarball and during Mono build run make in external/binary-reference-assemblies if they're missing.

[marek-safar]

I agree if this is for tarball build we should maybe not even package the cached dlls and just build them as part of basic profile

[directhex]

Do we need to add System.Net.Http.dll to monolite? It seems we reference it in our basic System.dll build

[directhex]

Observations on this:

• mcs/class/System/Makefile has API_BIN_REFS := System.Net.Http System.Xml but System.Net.Http is not in monolite - removing seems harmless?
• circular dependency issue between System.Web, System.Web.Services, System.Design

[marek-safar]

We don't want to add them to monolite. The change is not to bundle binaries from external/binary-reference-assemblies but build them during basic

[directhex]

So, current way to do a "full from-source" build:

• Strip out all assemblies, except mcs/class/lib/monolite-linux (and the others, if one feels so inclined) AND external/binary-reference-assemblies/v4.7.1/{Facades/}*.dll - i haven't found a sane way to disentangle the binary reference assemblies, but they ARE regenerated in this scenario
• Use --with-csc=mcs configure flag
• Patch mcs/tools/cil-stringreplacer/Makefile to use 4.7.1 profile, not 4.6
• Apply these 2 commits: https://github.com/mono/mono/pull/9831/files
• Patch mcs/class/Microsoft.Build.Tasks/Microsoft.Build.Tasks/Csc.cs to pass mcs.exe not csc.exe (so xbuild works without /p:CscToolExe=mcs)
• Apply this commit: akoeplinger/reference-assemblies@319c481
• BETWEEN MAKE AND MAKE INSTALL, delete *.dll from external/binary-reference-assemblies/v4.7.1{/Facades}
• Run MONO_PATH=/BUILDROOT/mcs/class/lib/net_4_x-linux/ V=1 CSC="/BUILDROOT/runtime/mono-wrapper /BUILDROOT/mcs/class/lib/net_4_x-linux/mcs.exe" make in external/binary-reference-assemblies

Seems to work, but obviously not well-integrated at this point in time

[aviau]

Hello,

It seems that Debian (and our derivatives) is stuck with an old build of mono because of this.

It looks like this issue was tagged as a "Proposal". Does that mean that there are no plans to implement it?

If there is anything that Debian can do to help, please let us know. I am not an expert of mono's build system so I might not be able to contribute to the core changes needed here, but I others might be able to.

Mono is a very popular Debian package, it would be a shame if we were stuck with 4.6 for the next Debian release.

[marek-safar]

It means it was not approved into our backlog at this point. The work should not be that complicated you would just need to call the existing Makefile https://github.com/mono/reference-assemblies/blob/master/Makefile to re-generate the references. The output will be same it's just redundant step for us.

[directhex]

Yeah, I'm working on it, declaring the entire v4.7.1 folder as "bootstrap" and regenerating the full set of reference assemblies during package build.

[aaronfranke]

When it comes to triaging: I would recommend solving this issue at least before 2019 ends, so that Ubuntu 20.04 LTS can ship with Mono 5.x. Ubuntu 18.10 still ships Mono 4.6.2.7 in its repos.

[directhex]

I have a 5.16 Debian-ready-in-theory package done, but it's blocked on unresolved MIPS build failures.

[jbicha]

Are there few enough mono packages in Debian to make it feasible to remove mono from mips?

I suppose it's too late to be doing something big like that for Debian Buster though. ☹️

[knocte]

blocked on unresolved MIPS build failures.

If you share a link to those maybe the community can help?

[directhex]

I'm closing this issue. 5.16+dfsg went into Debian last week, I just uploaded 5.18. There's a Process which works for now. I took this approach to deal with the bootstrap issue of the reference assemblies.

[knocte]

@directhex that's good to hear. Question: was msbuild part of that? or is that still shipping with xbuild only for now?

[directhex]

Xbuild. Msbuild is another thing entirely

[knocte]

@directhex hey, so Ubuntu 19.04 got mono 5.18 as well (thanks!), but this version has a very severe bug affecting pretty much any project (more info about it in these reports: https://bugzilla.redhat.com/show_bug.cgi?id=1704847 , https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919194, OpenRA/OpenRA#16441), even nuget (NuGet/Home#6735), so then it's hard to even build anything.

And it seems that 5.20 fixes this, reading from the reports. Any chance 5.20 can be uploaded, and/or the 5.18.x be patched with this patch https://src.fedoraproject.org/rpms/mono/blob/master/f/mono-5.18.0-largearraybuilder.patch to get picked up by Ubuntu as an update?