Tracking upstream bug here. Works with mono-2.2
Also present in pre2
The same here: cat ../../unxlngx6.pro/misc/ulfconv.ulfconv_1.cmd g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,--as-needed -Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,-rpath,'$ORIGIN:$ORIGIN/../ure-link/lib' -Wl,-export-dynamic -Wl,--noinhibit-exec -L../../unxlngx6.pro/lib ../../unxlngx6.pro/obj/ulfconv.o \ -Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -luno_sal -ldl -lpthread -lm -L../lib -L/var/tmp/portage/app-office/openoffice-3.0.1/work/ooo/build/ooo300-m15/solenv/unxlngx6/lib -L/var/tmp/portage/app-office/openoffice-3.0.1/work/ooo/build/ooo300-m15/solver/300/unxlngx6.pro/lib -L/var/tmp/portage/app-office/openoffice-3.0.1/work/ooo/build/ooo300-m15/solenv/unxlngx6/lib -L/opt/sun-jdk-1.6.0.12/lib64 -L/opt/sun-jdk-1.6.0.12/jre/lib/amd64 -L/opt/sun-jdk-1.6.0.12/jre/lib/amd64/server -L/opt/sun-jdk-1.6.0.12/jre/lib/amd64/native_threads -L/usr/lib -L/usr/lib64/xulrunner-1.9/sdk/lib -o ../../unxlngx6.pro/bin/ulfconv -rwxr-xr-x 1 root root 24607 Feb 9 11:08 ../../unxlngx6.pro/bin/ulfconv ------------- Running processes: 1 deliver -- version: 1.130 Module 'setup_native' delivered successfully. 60 files copied, 2 files unchanged top: top - 22:12:38 up 10 days, 8:54, 14 users, load average: 4.34, 8.64, 15.93 Tasks: 254 total, 1 running, 253 sleeping, 0 stopped, 0 zombie Cpu(s): 14.3%us, 7.1%sy, 0.0%ni, 15.9%id, 62.3%wa, 0.2%hi, 0.2%si, 0.0%st Mem: 7072600k total, 6935668k used, 136932k free, 139792k buffers Swap: 35672304k total, 23435904k used, 12236400k free, 71932k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30185 root 20 0 271m 178m 2240 R 25 2.6 0:14.00 emerge 297 root 15 -5 0 0 0 S 5 0.0 15:39.35 kswapd0 2966 root 15 -5 0 0 0 S 4 0.0 43:18.25 kcryptd 2914 root 15 -5 0 0 0 S 3 0.0 4:02.81 kcryptd 11668 rose 20 0 290m 6728 2212 R 3 0.1 1:10.89 gnome-terminal 25569 root 20 0 25.5g 5.1g 244 D 2 75.3 12:28.54 mono 11366 root 20 0 665m 67m 14m S 2 1.0 471:44.29 X
Hmm, perhaps the severity is a bit melodramatic. Resetting to normal. Pre3 is also affected.
Hard-masking the new mono is really a harsh move. Why not change OOo ebuild so that with USE=mono it depends on <mono-2.4? This bug does _not_ affect other mono users.
(In reply to comment #4) > Hard-masking the new mono is really a harsh move. Why not change OOo ebuild so > that with USE=mono it depends on <mono-2.4? This bug does _not_ affect other > mono users. > Well - if the mono is broken it is likely to be broken for other things too.
First, this is a mcs (compiler) problem, not a runtime problem. Second, please provide a _small_ reproduction test case to the upstream bug, nobody will be able to fix something that happens only when you are using a complex, custom build system with OOo patches that aren't even merged into the main tree.
Andreas: I masked the mono use-flag of unstable openoffice and upgraded the mono? deps to be <dev-lang/mono-2.4. Nothing much seems to use the mono bindings in openoffice, and we need to get mono-2.4 tested. +# Peter Alfredsen <loki_val@gentoo.org> (03 May 2009) +# Mask mono use-flag of unstable open-office w.r.t. +# bug 257313, since Novell seems disinclined to fix this +# in a timely manner. +>=app-office/openoffice-3.0.1 mono + + 03 May 2009; Peter Alfredsen <loki_val@gentoo.org> + openoffice-3.0.0.ebuild, openoffice-3.0.1.ebuild, + openoffice-3.1.0_beta7.ebuild: + Update deps w.r.t. bug 257313. Novell seems disinclined to fix this bug in + a timely manner, so we'll just have to work-around it. +
(In reply to comment #7) > Andreas: I masked the mono use-flag of unstable openoffice and upgraded the > mono? deps to be <dev-lang/mono-2.4. Nothing much seems to use the mono > bindings in openoffice, and we need to get mono-2.4 tested. Sounds good, thank you!
(In reply to comment #7) > +# Novell seems disinclined to fix this > +# in a timely manner. This seem typical for that bugzilla. After I asked a question there about our bug 220337 (executable stack on x86 - OK, so maybe the question was a bit silly), I got an answer after over five months, one that was off-topic.
(In reply to comment #9) > (In reply to comment #7) > > +# Novell seems disinclined to fix this > > +# in a timely manner. > This seem typical for that bugzilla. > After I asked a question there about our bug 220337 > (executable stack on x86 - OK, so maybe the question > was a bit silly), I got an answer after over five months, > one that was off-topic. > It's not typical for Novell Bugzilla in particular - it's typical for large and complex projects, especially when you report a bug without a good test case (read: less than 100 lines of code. 500 LOC in extreme cases). Please do not flame. Rafal, your executable stack concern looks like a valid one, but it should be directed to the developer mailing list. Mono Bugzilla is too huge for anyone to read all bug reports (I know this is a bad situation), people just check what gets assigned to them.
Well, the point of comment 9 (it was a bit flame-ish) - I asked a question that should be obvious to the person, who made that commit for 64bit - I waited for a few months - I raised some stink - I got an answer to a different question, one that I didn't asked What's more, the part: > if I remember correctly this is only on x86_64 because the on-executable > stack needs hardware and kernel support which exists on the AMD64, but not > necessarily on i386. means that I was probably right, as according to our stack guide, the problem with executable stack is that GNU ld marks unknown objects as needing executable stack *by default*, so it's not a *hardware* problem in the first place. And while I don't remember was the exact problems were, I do remember, that registering into that bugzilla was a real pain and there was something wrong with it afterwards (though it was not as broken (real technical issues) and useless (most problems are either solved on the mailing list or stay unsolved) as ALSA's bugtrack - a bug tracking "system" that exists for the sole purpose of existing). I'm registered to a few bugzillas and mono's was the second worst experience, right after ALSA. And I even would consider to be helpful here - if somebody told me what should I test to see if it works without executable stack and that test wouldn't need a lot of RAM/time, I'd probably test it. Now, I can only tell that mono can be built without it and still build trivial programs.
If you want to check whether your patch against mono doesn't break anything: - extract a mono tarball (or do an svn checkout, but this may be broken before you touch it ;-) ) - ./configure - make check If it passes, apply your changes and 'make check' again. If it doesn't pass before your changes - apply them anyway and check if it still breaks in the same place as before. If you need further, drop me an email/jabber message and I'll do my best.
JFYI, Petr Mladek filed a mono-2.4 feature with OOo to https://bugzilla.novell.com/show_bug.cgi?id=495112 ... with an untested workaround. Is it related?
Upstream claims to have fixed the bug on the trunk.
That seems to be the relevant patch: http://anonsvn.mono-project.com/viewvc/trunk/mcs/mcs/class.cs?r1=132861&r2=132860&pathrev=132861&view=patch
Yeah, I just have to downgrade from mono-9999 to get this tested. Trunk is failing on other stuff at the moment.
Fixed in mono-2.4-r2 (yay!). I'll get openoffice deps updated and mono use-flag unmasked.
