The command "emerge mono" should have had the binaries/class libs/etc. (it does in a directory, but it's not called upon) working to compile mcs. MONO_PATH=../../class/lib: mono ../../mcs/mcs.exe --target library --noconfig -o ../../class/lib/System.Web.dll -r corlib -r System -r System.Drawing -r System.Xml @.response The assembly corlib.dll was not found or could not be loaded. It should have been installed in the `/usr/lib' directory. make[2]: *** [../../class/lib/System.Web.dll] Error 1 make[2]: Leaving directory `/var/tmp/portage/mono-0.24-r1/work/mcs-0.24/class/System.Web' make[1]: *** [all] Error 1 make[1]: Leaving directory `/var/tmp/portage/mono-0.24-r1/work/mcs-0.24/class' make: *** [all] Error 1 !!! ERROR: dev-lang/mono-0.24-r1 failed. !!! Function src_compile, Line 41, Exitcode 2 !!! MCS compilation failure
BTW, my system isn't exactly rc4... It's one of those experimental LiveCDs that have the kernel 2.4.21 so I could install Gentoo with the typhoon ethernet card. (May LiveCD I believe). - Will
your 'emerge info' please
To foser: My `emerge info' : Portage 2.0.48-r1 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.21_rc6-gss i686 AMD Athlon(TM) XP 2100+ GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss 3dnow apm avi crypt cups encode gif jpeg libg++ libwww mikmod mmx mpeg ncurses nls pdflib png quicktime spell truetype xml2 xmms xv zlib gtkhtml alsa gdbm berkdb slang readline arts bonobo svga java guile mysql X sdl gpm tcpd pam ssl perl python esd imlib oggvorbis gnome gtk qt kde motif opengl mozilla cdr dvd gtk2 apache2" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -fprefetch-loop-arrays -funroll-loops" CXXFLAGS="-march=athlon-xp -O2 -pipe -fforce-addr -fomit-frame-pointer -falign-functions=4 -fprefetch-loop-arrays -funroll-loops" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
To everyone: By the way, here are two links, the first is the standard output and the second is the standard error from `emerge mono': http://stuff.digitizedweb.com/mono.txt http://stuff.digitizedweb.com/mono.err
im a bit confused now, the initial error and the one in #4 are from the same emerge . They don't look alike. First of all lower your optimizations (try with empty CFLAGS), see if that helps.
Foser: No they're not from the same emerge but I've been emerging it a million times, same thing. Remember that the .txt is the standard output and .err is the standard err. Look in .txt and you'll see some of initial error in #4. Actually, to make it easier.. here's the output of `emerge mono &> stdoutANDstderr.txt': http://stuff.digitizedweb.com/stdoutANDstderr.txt Before this, I've set CFLAGS to "march=athlon-xp -O2 -pipe", recompiled boehm-gc with these flags and then finally mono with the same flags. I talked to Todd and he now thinks I should re-emerge glibc with the above flags, so I'm doing so. I'll inform you all of the results.
This is an upstream issue most likely, im marking it as CANTFIX for now, will reopen if required
tberman : why do you think that is ? Closing without explanation isn't satisfactory. Anyway, i currently force full compilation while it isn't really necessary. Maybe i should make that optional (where the default is to compile everything). Actually atm i don't think compiling gets us any boost beyond using the gcc you want, since CFLAGS aren't passed on. Maybe we should work on that as well. Reporter have you built mono-0.20 in portage ? does that work allright ?
foser: sorry, the reporter and I have had extensive conversations on #mono and worked this over completely, it is a bug with the mono jitting engine and boehm-gc as when he compiles mono from tarball with --with-gc=none he has no issues at all. Seeing as he now not only has a working mono, but also has reported this bug upstream at my request, there is no reason to leave it open. We rebuilt boehm with standard safe CFLAGS and even went as far to rebuild glibc with the same safe CFLAGS. This is why I closed the bug. :)
i was aware of the fact that there was some real bug at hand, that doesn't change the fact that we can do a binary only install with the ebuild. Since this problem seems to happen during the mcs build we could disable that with some flag, i'm not against providing a workaround.
oh and there's another reason to keep this open, how can we track stuff if we close bugs while they're still a work in progress ? Reporter, can you please give us a link to the bug you filed ?
http://bugs.ximian.com/show_bug.cgi?id=44586 is the upstream bug.
the upstream bug is resolved / invalid for some time and it seems like the author's ram was b0rked...If he doesn't comment anymore I guess this bug can also be marked Invalid ? ("It is most likely my sticks of RAM. memtest86 claims all 1 GB of them fails the fifth test, [...]")
yeah sorry, this was discussed in IRC. shouldve been closed.
