Force MONO_CFG_DIR
cover Force MONO_CFG_DIR
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(+)
Signature · 1 line
2.4.4
RFC PATCH 1/1 mono.bbclass: set MONO_CFG_DIR
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.)
--- classes/mono.bbclass | 2 ++ 1 file changed, 2 insertions(+)
classes/mono.bbclass +2 -0
@@ -30,3 +30,5 @@ FILES_${PN}-dev += "\ FILES_${PN}-doc += "\ ${libdir}/monodoc/* \ " + +export MONO_CFG_DIR="${STAGING_ETCDIR_NATIVE}"
Signature · 1 line
2.4.4
Hi Richard,
Quoted 11 lines · 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.
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?
Quoted 10 lines
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:
Quoted 9 lines
git://github.com/rtollert/meta-monodev/rtollert/v5/mono-cfg
https://github.com/rtollert/meta-mono/tree/dev/rtollert/v5/mono-cfgRichard Tollerton (1):
mono.bbclass: setMONO_CFG_DIRclasses/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
Quoted 15 lines · Alex J Lennon
Hi Richard,
Quoted 11 lines · 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.
Quoted 8 lines
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!)
Quoted 9 lines
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.
Quoted 2 lines
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.
Quoted 11 lines
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.
Quoted 3 lines
Regards,
Alex
Quoted 23 lines · Richard Tollerton
Quoted 21 lines · Alex J Lennon
Hi Richard,
Quoted 11 lines · 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.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 -
Quoted 8 lines
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
Quoted 9 lines
Quoted 9 lines
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...
Quoted 8 lines
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.
Quoted 15 lines
Quoted 2 lines
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.
Quoted 6 lines
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...
Quoted 5 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 6 lines
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
Hi Richard,
Quoted 31 lines · Alex J Lennon
Quoted 29 lines · Richard Tollerton
Quoted 14 lines · Alex J Lennon
Hi Richard,
Quoted 11 lines · 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.Quoted 8 lines
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.
Quoted 22 lines
Quoted 2 lines
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
Quoted 17 lines
Quoted 9 lines
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
Quoted 5 lines · Alex J Lennon
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.
Quoted 1 line
dbus-sharp_0.8.0.bb
We might be able to work around this by setting $GMCS, judging from configure.ac.
Quoted 1 line
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.
Quoted 3 lines
Cheers,
Alex
Hi Richard,
Quoted 15 lines · Richard Tollerton
Quoted 5 lines · Alex J Lennon
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.
Quoted 1 line
dbus-sharp_0.8.0.bb
We might be able to work around this by setting $GMCS, judging from configure.ac.
Quoted 12 lines
Quoted 1 line
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.
Quoted 3 lines
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