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

Richard Tollerton rich.tollerton at ni.com
Fri Jul 17 11:24:17 PDT 2015


Alex J Lennon <ajlennon at 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



More information about the yocto mailing list