Same as bug #83164 - just with mono-1.1.10 now. Mono-1.1.10 fails to compile with the error that mcs.exe is not found. mcs.exe is the mono compiler, so of course it is not found prior to installation of mono, which requires mcs.exe ... The previous workaround that I've found was to install mono-1.0.6 - which, of course, is no longer available in the portage tree. I'm trying 1.1.8.3 right now. Reproducible: Always Steps to Reproduce: 1. emerge -C mono 2. emerge "=dev-lang/mono-1.1.10" 3. watch it fail Actual Results: Failed ebuild Expected Results: Successful compile/install of mono-1.1.10
Can you please post the actual error message you receive when trying to install mono-1.1.10 on a fresh system? (Please include as much of the build output as possible to not miss anything). Also, please post the output of 'emerge info' as well. This may exhibit the same behaviour, but I need the exact error for 1.1.10 to try to track down why this might be the case. Thanks.
Created attachment 74108 [details] emerge info as requested
Created attachment 74109 [details] mono-1.1.10 compile error As follows: if test -w ../mcs; then :; else chmod -R +w ../mcs; fi cd ../mcs && make PROFILES='default net_2_0' all-profiles make[3]: Entering directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make profile-do--default--all profile-do--net_2_0--all make[4]: Entering directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make PROFILE=basic all make[5]: Entering directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make[6]: mcs: Command not found make[6]: *** [build/deps/basic-profile-check.exe] Error 127 make[6]: Entering directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' *** The compiler 'mcs' doesn't appear to be usable. *** Trying the 'monolite' directory. make[7]: Entering directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' sem_wait failed make[8]: *** [build/deps/basic-profile-check.exe] Aborted make[8]: Entering directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' *** The contents of your 'monolite' directory may be out-of-date *** You may want to try 'make get-monolite-latest' make[8]: *** [do-profile-check-monolite] Error 1 make[8]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make[7]: *** [do-profile-check] Error 2 make[7]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make[6]: *** [do-profile-check-monolite] Error 2 make[6]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make[5]: *** [do-profile-check] Error 2 make[5]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make[4]: *** [profile-do--basic--all] Error 2 make[4]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make[3]: *** [profiles-do--all] Error 2 make[3]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/mcs' make[2]: *** [all-local] Error 2 make[2]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/mono-1.1.10/work/mono-1.1.10' make: *** [all] Error 2 !!! ERROR: dev-lang/mono-1.1.10 failed. !!! Function src_compile, Line 74, Exitcode 2 !!! MONO compilation failure !!! If you need support, post the topmost build error, NOT this status message.
The 'sem_wait failed' line there is ultimately the source of the problem. That's probably the GC freaking out, which results in 'mcs' appearing unusable, which results in the error. Can you please try with CFLAGS="-pipe" and see if there is any difference?
(In reply to comment #4) > The 'sem_wait failed' line there is ultimately the source of the problem. That's > probably the GC freaking out, which results in 'mcs' appearing unusable, which > results in the error. Can you please try with CFLAGS="-pipe" and see if there is > any difference? Exact same error, line for line...
(In reply to comment #5) > (In reply to comment #4) > > The 'sem_wait failed' line there is ultimately the source of the problem. That's > > probably the GC freaking out, which results in 'mcs' appearing unusable, which > > results in the error. Can you please try with CFLAGS="-pipe" and see if there is > > any difference? > > Exact same error, line for line... > Would the sem_wait error be affected at all by what kernel I am running? I wouldn't think so, but I am currently running Ingo Molnars realtime-preempt patch (2.6.14.4-rt22). If that might be it, I can boot a standard gentoo-sources kernel and try again. -James
Seems unlikely, but could very well be. Couldn't hurt to try.
(In reply to comment #7) > Seems unlikely, but could very well be. Couldn't hurt to try. OK, rebooted into a non-RT-patched kernel, and it compiled perfectly... So, is the system going to blow up when I run mono-dependant stuff (such as Gnome et al.) under the RT kernel? Well, at least we know that the current mono build isn't compatible (at least at compile-time) with the RT kernel - I'll let you know how much smoke is let out when I try using the (now) compiled mono on the RT kernel. :) -James
In all likelyhood, any mono using apps will go boom using that kernel yes. Probably the RT kernel is doing funky thread/process stuff to achieve the RT-ness and that's making libgc unhappy. You'll probably end up getting those sem_wait failed error messages in apps you try to run while using that kernel. I'm marking this WONTFIX, using random kernel X you take the risk of things like this happening. (:
(In reply to comment #9) > In all likelyhood, any mono using apps will go boom using that kernel yes. > Probably the RT kernel is doing funky thread/process stuff to achieve the > RT-ness and that's making libgc unhappy. You'll probably end up getting those > sem_wait failed error messages in apps you try to run while using that kernel. > > I'm marking this WONTFIX, using random kernel X you take the risk of things like > this happening. (: Makes perfect sense. :) However, one thing to note - more and more of Ingo's RT patchset is making it's way into mainline with every release - with the endpoint of mainline being fully realtime & preemptible capable - so, it will probably need to be dealt with at one point or another - I'm guessing that this is an upstream thing anyway, but I don't know if they realize that this happens. Thanks for your time! -James
