| Summary: | mono-1.1.10 ebuild depends on mcs.exe to already be there - not there if it is a fresh install of mono | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | James Ausmus <james.ausmus> |
| Component: | Current packages | Assignee: | dotnet project <dotnet> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge info as requested
mono-1.1.10 compile error |
||
|
Description
James Ausmus
2005-12-05 09:43:08 UTC
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 |
