[meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Richard Tollerton]

Hi Alex,

When you mentioned having weird build troubles, that reminded me that I
was seeing weird build problems of my own, that I had been refraining
from sending patches on until I could better characterize the issue.

If you've been seeing weird build failures in executables that really
should never be failing in the first place -- i.e., gacutils failures,
or "invalid resx file", or anything involving not being able to dlopen
libc or being unable to open /etc/mono/config -- you might be interested
in this patch.

That said, if you *don't* have problems compiling to an ARM sysroot, I'd
be interested in knowing that too. :F


The following changes since commit 041cc6b70c7fb3b55e73b90b1a101844da1726b2:

  README: Update to remove references to mono < 3.12.1 (2015-07-17 12:38:32 +0100)

are available in the git repository at:

  git://github.com/rtollert/meta-mono dev/rtollert/v5/mono-cfg
  https://github.com/rtollert/meta-mono/tree/dev/rtollert/v5/mono-cfg

Richard Tollerton (1):
  mono.bbclass: set MONO_CFG_DIR

 classes/mono.bbclass | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.4.4

[meta-mono] [RFC] [PATCH 1/1] mono.bbclass: set MONO_CFG_DIR

[Richard Tollerton]

Several mono package builds were observed to fail while cross-compiling
to arm in ways that, upon stracing, boiled down to not being able to
load the mono config file because mono was looking for it in
${STAGING_DIR_NATIVE}/usr/etc instead of
${STAGING_DIR_NATIVE}/etc (which is where it was being installed).

mono/mono/metadata/assembly.c:set_dirs() appears to be responsible for
guessing /usr/etc, by essentially computing $(dirname $0)/../etc.
There's a separate codepath that instead chooses $sysconfdir (cf
assembly.c:fallback(), mono-config-dirs.c:mono_config_get_cfg_dir(), and
the Makefile). Presumably that's what's usually used for native mono
builds, but for presently unknown reasons, it's not getting used here.

The workaround implemented here is to force setting MONO_CFG_DIR for all
builds to the correct location of /etc in the native sysroot.
(I had earlier worked around this by changing the mono-native build to
install to /usr/etc instead of /etc, but that's more complicated to
manage in the recipes, and violates the configuration symmetry between
architectures.)

Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
---
 classes/mono.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/classes/mono.bbclass b/classes/mono.bbclass
index 315ee82..1cb4b17 100644
--- a/classes/mono.bbclass
+++ b/classes/mono.bbclass
@@ -30,3 +30,5 @@ FILES_${PN}-dev += "\
 FILES_${PN}-doc += "\
   ${libdir}/monodoc/* \
 "
+
+export MONO_CFG_DIR="${STAGING_ETCDIR_NATIVE}"
-- 
2.4.4

Re: [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Alex J Lennon]

Hi Richard,

On 17/07/2015 17:57, Richard Tollerton wrote:
> Hi Alex,
>
> When you mentioned having weird build troubles, that reminded me that I
> was seeing weird build problems of my own, that I had been refraining
> from sending patches on until I could better characterize the issue.
>
> If you've been seeing weird build failures in executables that really
> should never be failing in the first place -- i.e., gacutils failures,
> or "invalid resx file", or anything involving not being able to dlopen
> libc or being unable to open /etc/mono/config -- you might be interested
> in this patch.

I think I have identified the problems I was seeing with the recipes,
which boil down to the lack of a mono gmcs script and inheriting
autotools-brokensep instead of autotools.

I can't quite understand why you were not seeing the problem at your
end, but I can see that gmcs was removed at end 2014 -

https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568

The commits I made today address the autotools-brokensep issue and get
me to a point where I can build image-full-mono with a hand-added gmcs
script in sysroot

(There was a patch needed for monotools-server to support the more
recent mono-xsp and mono-upnp needed autotools-brokensep).

Now I just need to decide whether to reintroduce the gmcs script or fix
all the other autotools configurations...

I am probably going to reintroduce the script due to time contraints
unless you want to take a look at this?

> That said, if you *don't* have problems compiling to an ARM sysroot, I'd
> be interested in knowing that too. :F
>
>
> The following changes since commit 041cc6b70c7fb3b55e73b90b1a101844da1726b2:
>
>   README: Update to remove references to mono < 3.12.1 (2015-07-17 12:38:32 +0100)
>
> are available in the git repository at:
>
>   git://github.com/rtollert/meta-mono dev/rtollert/v5/mono-cfg
>   https://github.com/rtollert/meta-mono/tree/dev/rtollert/v5/mono-cfg
>
> Richard Tollerton (1):
>   mono.bbclass: set MONO_CFG_DIR
>
>  classes/mono.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
>

I use mono primarily on ARM (i.MX6) - commercially, quite a lot - and
haven't seen anything that was problematical with the build for some
time, since I addressed some issues with use of out of tree mono
installed on the host.

So from my experience "all is well" with Mono ARM builds. I'd like to
know about any issues you or others have seen on ARM platforms though
which we need to address.

That said, I can't see any reason not to apply your patch so will merge
that in.

Regards,

Alex

Re: [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Richard Tollerton]

Alex J Lennon <ajlennon@dynamicdevices.co.uk> writes:

> Hi Richard,
>
> On 17/07/2015 17:57, Richard Tollerton wrote:
>> Hi Alex,
>>
>> When you mentioned having weird build troubles, that reminded me that I
>> was seeing weird build problems of my own, that I had been refraining
>> from sending patches on until I could better characterize the issue.
>>
>> If you've been seeing weird build failures in executables that really
>> should never be failing in the first place -- i.e., gacutils failures,
>> or "invalid resx file", or anything involving not being able to dlopen
>> libc or being unable to open /etc/mono/config -- you might be interested
>> in this patch.
>
> I think I have identified the problems I was seeing with the recipes,
> which boil down to the lack of a mono gmcs script and inheriting
> autotools-brokensep instead of autotools.
>
> I can't quite understand why you were not seeing the problem at your
> end, but I can see that gmcs was removed at end 2014 -
>
> https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568

Yeah, I saw it too. :F I wound up working around it by adding a gmcs
symlink in the recipe, but then I also added a gmcs symlink in my host
OS, which wound up masking the build errors when I tried removing the
gmcs symlink from the recipe later.

There were also some autotools-brokensep build problems I was planning
on submitting later, sounds like you got those fixed first (yay!)

> The commits I made today address the autotools-brokensep issue and get
> me to a point where I can build image-full-mono with a hand-added gmcs
> script in sysroot
>
> (There was a patch needed for monotools-server to support the more
> recent mono-xsp and mono-upnp needed autotools-brokensep).
>
> Now I just need to decide whether to reintroduce the gmcs script or fix
> all the other autotools configurations...

A-ha! mono-xsp fixed its gmcs references in master, but hasn't cut a
release since May 2013. I just asked on #monodev for somebody to cut a
new release, but until then, I suppose a workaround is to create a
mono-xsp_git.bb?

Which other packages require gmcs? I see that monotools-server does, but
I can't find evidence of that being maintained since 2010, and I
otherwise don't have a use for it AFAIK.

> I am probably going to reintroduce the script due to time contraints
> unless you want to take a look at this?

Yeah, go for it.

I asked on #monodev whether there was any downside to symlinking gmcs to
mcs, and at least one person responded in the negative. But IIRC, at the
same time, nobody expressed any surprise that this isn't done already,
which is kinda weird. I did do some grepping through the mono codebase
and was unable to find any behavioral changes that were keyed off
executing mcs as gmcs, so obviously it's going to emit 4.5-compatible
stuff which isn't ideal, but it does get stuff building.

I presume that your script solution restricts assembly versions
appropriately and the like and tries to do The Right Thing.

See also
https://github.com/mono/mono/commit/6b76c7e984cbe42d6455ffcde2fe227aa5ffd801,
which was breaking mono-xsp when build with gmcs symlinked to mcs. I
presume you didn't encounter this with your script because it's properly
behaving like gmcs, but once these mono-xsp gmcs fixes roll in, this
will probably start breaking stuff.

> I use mono primarily on ARM (i.MX6) - commercially, quite a lot - and
> haven't seen anything that was problematical with the build for some
> time, since I addressed some issues with use of out of tree mono
> installed on the host.
>
> So from my experience "all is well" with Mono ARM builds. I'd like to
> know about any issues you or others have seen on ARM platforms though
> which we need to address.
>
> That said, I can't see any reason not to apply your patch so will merge
> that in.

Thanks. I'll try to dig deeper into this soon, and will work upstream
with the mono devs when I get to the bottom of it.

> Regards,
>
> Alex

Re: [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Alex J Lennon]

On 17/07/2015 19:24, Richard Tollerton wrote:
> Alex J Lennon <ajlennon@dynamicdevices.co.uk> writes:
>
>> Hi Richard,
>>
>> On 17/07/2015 17:57, Richard Tollerton wrote:
>>> Hi Alex,
>>>
>>> When you mentioned having weird build troubles, that reminded me that I
>>> was seeing weird build problems of my own, that I had been refraining
>>> from sending patches on until I could better characterize the issue.
>>>
>>> If you've been seeing weird build failures in executables that really
>>> should never be failing in the first place -- i.e., gacutils failures,
>>> or "invalid resx file", or anything involving not being able to dlopen
>>> libc or being unable to open /etc/mono/config -- you might be interested
>>> in this patch.
>> I think I have identified the problems I was seeing with the recipes,
>> which boil down to the lack of a mono gmcs script and inheriting
>> autotools-brokensep instead of autotools.
>>
>> I can't quite understand why you were not seeing the problem at your
>> end, but I can see that gmcs was removed at end 2014 -
>>
>> https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568
> Yeah, I saw it too. :F I wound up working around it by adding a gmcs
> symlink in the recipe, but then I also added a gmcs symlink in my host
> OS, which wound up masking the build errors when I tried removing the
> gmcs symlink from the recipe later.
>
> There were also some autotools-brokensep build problems I was planning
> on submitting later, sounds like you got those fixed first (yay!)

Good - that explains it then. Yes autotools-brokensep is in there now.
The gmcs workaround will arrive shortly

>> The commits I made today address the autotools-brokensep issue and get
>> me to a point where I can build image-full-mono with a hand-added gmcs
>> script in sysroot
>>
>> (There was a patch needed for monotools-server to support the more
>> recent mono-xsp and mono-upnp needed autotools-brokensep).
>>
>> Now I just need to decide whether to reintroduce the gmcs script or fix
>> all the other autotools configurations...
> A-ha! mono-xsp fixed its gmcs references in master, but hasn't cut a
> release since May 2013. I just asked on #monodev for somebody to cut a
> new release, but until then, I suppose a workaround is to create a
> mono-xsp_git.bb?
>
> Which other packages require gmcs? I see that monotools-server does, but
> I can't find evidence of that being maintained since 2010, and I
> otherwise don't have a use for it AFAIK.

I'd have to check. I think there were a couple of others but adding in
gmcs made all the problems "disappear" so I didn't investigate further.

If I get a chance I may remove tmp/ and rebuild without the gmcs patch
to see what breaks.

monotools-server is there because I want to be able to remote debug onto
ARM platforms with Visual Studio (or Xamarin IDE if I have to) Some time
ago Xamarin had a neat Visual Studio plugin that supported this but
unfortunately it has disappeared. Xamarin IDE can be  configured to
remote debug against Mono/Arm/Linux and I've had some success with
trivial applications but I really want to find time to get this up and
running for more complex commercial applications.

>> I am probably going to reintroduce the script due to time contraints
>> unless you want to take a look at this?
> Yeah, go for it.
>
> I asked on #monodev whether there was any downside to symlinking gmcs to
> mcs, and at least one person responded in the negative. But IIRC, at the
> same time, nobody expressed any surprise that this isn't done already,
> which is kinda weird. I did do some grepping through the mono codebase
> and was unable to find any behavioral changes that were keyed off
> executing mcs as gmcs, so obviously it's going to emit 4.5-compatible
> stuff which isn't ideal, but it does get stuff building.
>
> I presume that your script solution restricts assembly versions
> appropriately and the like and tries to do The Right Thing.
>
> See also
> https://github.com/mono/mono/commit/6b76c7e984cbe42d6455ffcde2fe227aa5ffd801,
> which was breaking mono-xsp when build with gmcs symlinked to mcs. I
> presume you didn't encounter this with your script because it's properly
> behaving like gmcs, but once these mono-xsp gmcs fixes roll in, this
> will probably start breaking stuff.

I wasn't keen on symlinking, so in the short term I am looking at just
reverting the patch I referenced which removed gmcs.

I can believe that may lead us onto other issues but at least it is a
step in the right direction as the recipes will at least build...

>> I use mono primarily on ARM (i.MX6) - commercially, quite a lot - and
>> haven't seen anything that was problematical with the build for some
>> time, since I addressed some issues with use of out of tree mono
>> installed on the host.
>>
>> So from my experience "all is well" with Mono ARM builds. I'd like to
>> know about any issues you or others have seen on ARM platforms though
>> which we need to address.
>>
>> That said, I can't see any reason not to apply your patch so will merge
>> that in.
> Thanks. I'll try to dig deeper into this soon, and will work upstream
> with the mono devs when I get to the bottom of it.

Great!

Cheers,

Alex

Re: [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 3765 bytes --]

Hi Richard,

On 17/07/2015 19:44, Alex J Lennon wrote:
>
> On 17/07/2015 19:24, Richard Tollerton wrote:
>> Alex J Lennon <ajlennon@dynamicdevices.co.uk> writes:
>>
>>> Hi Richard,
>>>
>>> On 17/07/2015 17:57, Richard Tollerton wrote:
>>>> Hi Alex,
>>>>
>>>> When you mentioned having weird build troubles, that reminded me that I
>>>> was seeing weird build problems of my own, that I had been refraining
>>>> from sending patches on until I could better characterize the issue.
>>>>
>>>> If you've been seeing weird build failures in executables that really
>>>> should never be failing in the first place -- i.e., gacutils failures,
>>>> or "invalid resx file", or anything involving not being able to dlopen
>>>> libc or being unable to open /etc/mono/config -- you might be interested
>>>> in this patch.
>>> I think I have identified the problems I was seeing with the recipes,
>>> which boil down to the lack of a mono gmcs script and inheriting
>>> autotools-brokensep instead of autotools.
>>>
>>> I can't quite understand why you were not seeing the problem at your
>>> end, but I can see that gmcs was removed at end 2014 -
>>>
>>> https://github.com/mono/mono/commit/b304ec5e0e694ef7098e0fc3eba9dbc0162f4568
>> Yeah, I saw it too. :F I wound up working around it by adding a gmcs
>> symlink in the recipe, but then I also added a gmcs symlink in my host
>> OS, which wound up masking the build errors when I tried removing the
>> gmcs symlink from the recipe later.
>>
>> There were also some autotools-brokensep build problems I was planning
>> on submitting later, sounds like you got those fixed first (yay!)
> Good - that explains it then. Yes autotools-brokensep is in there now.
> The gmcs workaround will arrive shortly
>
>>> The commits I made today address the autotools-brokensep issue and get
>>> me to a point where I can build image-full-mono with a hand-added gmcs
>>> script in sysroot
>>>
>>> (There was a patch needed for monotools-server to support the more
>>> recent mono-xsp and mono-upnp needed autotools-brokensep).
>>>
>>> Now I just need to decide whether to reintroduce the gmcs script or fix
>>> all the other autotools configurations...
>> A-ha! mono-xsp fixed its gmcs references in master, but hasn't cut a
>> release since May 2013. I just asked on #monodev for somebody to cut a
>> new release, but until then, I suppose a workaround is to create a
>> mono-xsp_git.bb?
>>
>> Which other packages require gmcs? I see that monotools-server does, but
>> I can't find evidence of that being maintained since 2010, and I
>> otherwise don't have a use for it AFAIK.

Out of image-full-mono these have problems without gmcs present,

Looks like we need a solution for these three to use mcs instead of gmcs,

mono-xsp_3.0.11.bb

checking for gmcs... no
configure: WARNING: unrecognized options: --disable-dependency-tracking,
--with-libtool-sysroot
configure: WARNING: using cross tools not prefixed with host triplet
configure: error: You need to install 'gmcs'
Error: Could not run ./configure, which is required to configure xsp

dbus-sharp_0.8.0.bb

checking for MONO... yes
checking for gmcs... no
configure: error: You need to install gmcs
Configure failed. The contents of all config.log files follows to aid
debugging

mono-addins_1.1.bb

checking for pkg-config...
/data_drive/imx6/rootfs_builder/qemux86.dizzy/tmp/sysroots/x86_64-linux/usr/bin/pkg-config
checking for gmcs... no
configure: error: mcs Not found
Configure failed. The contents of all config.log files follows to aid
debugging

...

mono-upnp (requires mono-addins)
dbus-sharp-glib (requires dbus-sharp)
monotools-server (requires mono-xsp)

Cheers,

Alex


[-- Attachment #2: Type: text/html, Size: 5371 bytes --]

Re: [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Richard Tollerton]

Alex J Lennon <ajlennon@dynamicdevices.co.uk> writes:

> Out of image-full-mono these have problems without gmcs present,
>
> Looks like we need a solution for these three to use mcs instead of gmcs,
>
> mono-xsp_3.0.11.bb

I guess I'm the least concerned about this because of the fixes applied
in git. They still haven't cut a release yet so I'd guess we should just
create a mono-xsp_git.bb.

> dbus-sharp_0.8.0.bb

We might be able to work around this by setting $GMCS, judging from
configure.ac.

> mono-addins_1.1.bb

We might be able to work around this by setting $MCS, judging from
configure.ac.

Beyond that, I suppose the most OE-y way of solving this would be to
promote your script to a full-blown package that PROVIDES gmcs, such
that mono3 PROVIDES gmcs and mcs, but mono4 only PROVIDES mcs. Or
something like that.

> Cheers,
>
> Alex

Re: [meta-mono] [RFC] [PATCH 0/1] Force MONO_CFG_DIR

[Alex J Lennon]

Hi Richard,

On 20/07/2015 19:11, Richard Tollerton wrote:
> Alex J Lennon <ajlennon@dynamicdevices.co.uk> writes:
>
>> Out of image-full-mono these have problems without gmcs present,
>>
>> Looks like we need a solution for these three to use mcs instead of gmcs,
>>
>> mono-xsp_3.0.11.bb
> I guess I'm the least concerned about this because of the fixes applied
> in git. They still haven't cut a release yet so I'd guess we should just
> create a mono-xsp_git.bb.
>
>> dbus-sharp_0.8.0.bb
> We might be able to work around this by setting $GMCS, judging from
> configure.ac.
>
>> mono-addins_1.1.bb
> We might be able to work around this by setting $MCS, judging from
> configure.ac.
>
> Beyond that, I suppose the most OE-y way of solving this would be to
> promote your script to a full-blown package that PROVIDES gmcs, such
> that mono3 PROVIDES gmcs and mcs, but mono4 only PROVIDES mcs. Or
> something like that.
>
>> Cheers,
>>
>> Alex

I did a set of work today to bring the recipes up to use mcs instead of
gmcs.

Maybe you can take a look? Thanks,

Alex