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

[Alex J Lennon <ajlennon@dynamicdevices.co.uk>]

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