Add support for mono 6.8.x

[ThadHouse]

If you haven't started on this, I plan on cleaning up my fork where I got 6.8 working. I can easily PR it after cleaning it up.

https://github.com/ThadHouse/meta-mono/tree/frc2020

[cmcqueen]

Is this issue resolved, or does it need to be re-opened until an issue with pull #20 is fixed?

[ajlennon]

My baseline at the moment (although this really needs significant improvement) is that the testimage should complete successfully:

bitbake core-image-mono -c testimage

That basically runs a compile and execution of a command line HelloWorld, a Windows Forms one, and a GTK one.

So yes, for Mono to be supported all of the above should complete successfully so I'll reopen

[zboszor]

When building as RPM, this prevents building an image using Mono 6.8:

ERROR: mono-6.8.0.96-r0 do_package_qa: QA Issue: /usr/lib/mono/4.5/System.Memory.dll contained in package mono-libs-4.5 requires mono(System.Buffers), but no providers found in RDEPENDS_mono-libs-4.5? [file-rdeps]
ERROR: mono-6.8.0.96-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: mono-6.8.0.96-r0 do_package_qa: 
ERROR: mono-6.8.0.96-r0 do_package_qa: Function failed: do_package_qa

[zboszor]

According to https://www.mono-project.com/docs/about-mono/releases/6.4.0/#libgdiplus-update-to-602 , a newer libgdiplus is expected by Mono 6.4.0+. See https://github.com/DynamicDevices/meta-mono/pull/23

[ajlennon]

Good catch! I guess we best update!

[mnme]

I have a working recipe for libgdiplus 6.0.2 (and mono 6.4), are you interested in a pull request?

[ajlennon]

Yes please @mnme !

[zboszor]

@ajlennon What can we do about the rpm packaging error?

ERROR: mono-6.8.0.96-r0 do_package_qa: QA Issue: /usr/lib/mono/4.5/System.Memory.dll
contained in package mono-libs-4.5 requires mono(System.Buffers), but no providers found in
RDEPENDS_mono-libs-4.5? [file-rdeps]

mono(System.Buffers) a.k.a. System.Buffers.dll is built under several versions of the Roslyn compiler in the Mono 6.8 source tree but it doesn't get installed or packaged anywhere.

[ajlennon]

If the dependency is correct then presumably we should package this? What do you think?

[zboszor]

The first thing that popped out is that the versioned compiler directories do not directly match the relevant dotNet version, for one I haven't seen a 4.x version. Another question is whether the Mono runtime implicitly provides the functionality of this DLL. In which case we should just add the synthetic RPROVIDES_${PN}-pkg += "mono(System.Buffers)" line to relevant subpackages. But I am not really familiar with the Mono internals enough to know the answer.

[ajlennon]

@zboszor

I'm not getting a QA packaging error here with RPM. core-image-mono builds

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "x86_64-poky-linux"
MACHINE              = "qemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0.1"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "zeus:c1d49a3741183180b9e27f9d4dca1dbbe7232b87"
meta-mono            = "master:bb6c7d887bd20bdd7c16ba9aaf37df2b24055f01"
meta-oe              = "zeus:e855ecc6d35677e79780adc57b2552213c995731"

[ajlennon]

OK so I am now building mono-helloworld OK and when I test in QEMU I get this

[ajlennon]

OK I think the dllmap patch is incorrect. Will fix up

[ThadHouse]

I had to install the dev package to solve that issue. But if dllmap can fix that issue that would be better. I just assumed something had changed in the low level build.

[mnme]

So I have a working mono 6.4 (at least for me it works on a imx6 board running windows forms), but I didn't have the time so far to merge it with the 6.8 recipe and includes so far. Should I push that to a branch on my fork, so you can see if you can use some parts of that?

[ajlennon]

Leave it with me for a moment and I'll try to sort out the 6.8 stuff first :)

[zboszor]

@zboszor

I'm not getting a QA packaging error here with RPM. core-image-mono builds

Build Configuration:
BB_VERSION           = "1.44.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "universal"
TARGET_SYS           = "x86_64-poky-linux"
MACHINE              = "qemux86-64"
DISTRO               = "poky"
DISTRO_VERSION       = "3.0.1"
TUNE_FEATURES        = "m64 core2"
TARGET_FPU           = ""
meta                 
meta-poky            
meta-yocto-bsp       = "zeus:c1d49a3741183180b9e27f9d4dca1dbbe7232b87"
meta-mono            = "master:bb6c7d887bd20bdd7c16ba9aaf37df2b24055f01"
meta-oe              = "zeus:e855ecc6d35677e79780adc57b2552213c995731"

I am still on warrior, although not using "poky" directly, it's our custom distro. The only thing I can think of that can influence RPM packaging is signing, although it shouldn't influence the Depends/Provides clauses in RPM packages:

PACKAGE_CLASSES = "package_rpm sign_rpm"

[ajlennon]

I can give it a go...

[ajlennon]

I've been all around the houses and PR #28 gets mono building by packaging libmono-native.so in mono-libs. The helloworld and helloworldgtk tests run but helloworldforms still fails

[ajlennon]

@zboszor - configured it up to sign the RPMs and that all worked fine

[zboszor]

I've been all around the houses and PR #28 gets mono building by packaging libmono-native.so in mono-libs. The helloworld and helloworldgtk tests run but helloworldforms still fails

For a fix of referencing libmono-native.so in the dllmap, see:

https://github.com/DynamicDevices/meta-mono/blob/master/recipes-mono/mono/mono-5.20.1.34/dllmap-config.in.diff#L19

[ajlennon]

Yeah that looks like one of the things I tried. Failed to build

[ajlennon]

Finally got the tests passing so am closing this one down!

http://jenkins.dynamicdevices.co.uk:8080/job/meta-mono/164/console

[zboszor]

In the meantime I switched to Zeus and the previously quoted RPM package dependency issue from Warrior does not occur.