Closed ajlennon closed 4 years ago
Is this issue resolved, or does it need to be re-opened until an issue with pull #20 is fixed?
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
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
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
Good catch! I guess we best update!
I have a working recipe for libgdiplus 6.0.2 (and mono 6.4), are you interested in a pull request?
Yes please @mnme !
@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.
If the dependency is correct then presumably we should package this? What do you think?
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.
@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"
OK so I am now building mono-helloworld OK and when I test in QEMU I get this
OK I think the dllmap patch is incorrect. Will fix up
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.
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?
Leave it with me for a moment and I'll try to sort out the 6.8 stuff first :)
@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"
I can give it a go...
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
@zboszor - configured it up to sign the RPMs and that all worked fine
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:
Yeah that looks like one of the things I tried. Failed to build
Finally got the tests passing so am closing this one down!
http://jenkins.dynamicdevices.co.uk:8080/job/meta-mono/164/console
In the meantime I switched to Zeus and the previously quoted RPM package dependency issue from Warrior does not occur.
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