Summary: | dev-lang/mono: ebuild not quite correct and executable stack | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Rafał Mużyło <galtgendo> |
Component: | Current packages | Assignee: | dotnet project <dotnet> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | flameeyes, jacobgodserv, mikel, mrdanwallis, skolima, uvcrew |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.novell.com/show_bug.cgi?id=439086#c6 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Rafał Mużyło
2008-05-05 10:21:18 UTC
In case you missed this part: this bug affects 1.9 series too. The libtool issues definitely should be forwarded to mono-devel mailing list for clarification (you won't get a response here because this is "good enough"). As for use-monolite, this is supposed to get a minimal mono runtime for use with the compilation (when mono is not yet installed or broken). However, this is discouraged by upstream, as monolite is generated nigthly and thus the download is unusable sometimes. Please explain: you said: "As for use-monolite,....this is discouraged by upstream" but the ebuild tries to do it anyway, of course, it doesn't actually do it, due to the problem I mentioned. As for the libtool, I'm not really an expert, I just learned some stuff here (mainly during libtool 2 transition), so they (the upstream) would probably ignore me anyway. And as for mono, I don't now anything about it, things I'm reporting are build issues, not something really mono-related. I on the other hand don't know anything about libtool, but I'm quite good with mono. If the get-monolite-latest doesn't work in the ebuild as you say, then it is not possible to install mono on gentoo (it would be possible to update it - mono requires a working mcs in PATH to build). I'll check it in a while, but I doubt whether this is really true. Just to make sure we're talking about the same thing: what do you mean by: "If the get-monolite-latest doesn't work", I'm only saying, that `touch "${S}"/mcs/build/deps/use-monolite` results in: touch: nie można dotknąć `/var/tmp/portage/dev-lang/mono-2.0/work/mono-2.0/mcs/build/deps/use-monolite': Nie ma takiego pliku ani katalogu On a related note: can anything be done about executable stack warnings at the merge phase ? As for the libtool, once again: in configure.in first time they call libtool is before it gets generated (this is regardless of whether it's libtool 1.5 or 2); as for the checks themselves: if I correctly understood a few posts on libtool mailing list, most libtool vars can be checked by configure directly, ever since libtool 1.4; I can't really say much about the second check as I don't have any experience with cygwin, but somehow I suspect a case of self-harm. I did some checking about executable stacks. They seem to come from mono/mini/mdb-debug-info32.s The interesting part about it is that mono/mini/mdb-debug-info64.s does have '.section .note.GNU-stack, "", @progbits' line when that file lacks it. Is there some reason for this or is it simply an oversight ? BTW, while (as I alredy mentioned) I have no experiences with cygwin, it looks like that that mono devs used won't work for libtool 2 (and that's even LT_OUTPUT issue aside). Only place the hack seem to affect was AC_LIBTOOL_SYS_DYNAMIC_LINKER. In libtool 2, it's in lt~obsolete.m4 file, as in "macros libtool no longer uses". Or, more exactly, "those, that are AC_DEFUN'ed to '' ". FYI: I pushed the executable stack question upstream https://bugzilla.novell.com/show_bug.cgi?id=439086 but no answer yet. To update status: in mono 2.2, part of the first problem was addressed - check for '-Wl,--export-dynamic' was moved after the point where libtool 1.5 gets generated. The rest remains - even my question about that 32 vs 64 difference. *** Bug 264452 has been marked as a duplicate of this bug. *** dev-lang/mono-2.4.2.3 (and 2.6) seems to not show executable stacks for me on x86 :-/ What of these problems are still valid (and fixable downstream) with mono-2.6? Without the trivial patch (in mono 2.6.4): scanelf -qa libmono.so.0.0.0 0755 LE RWX --- --- libmono.so.0.0.0 scanelf -qa mono 0755 LE RWX --- --- mono and the input in the upstream bug makes it clear, upstream is *unwilling* to fix it. No change (from my last comment) about the libtool part. It may not be a big problem (hard to tell), but it still is incorrect. (In reply to comment #13) > Without the trivial patch (in mono 2.6.4): Sorry but, what trivial patch are you referring to? > and the input in the upstream bug makes it clear, > upstream is *unwilling* to fix it. > > No change (from my last comment) about the libtool part. > It may not be a big problem (hard to tell), but it still is incorrect. > Have you reported this second problem to upstream? (In reply to comment #14) > (In reply to comment #13) > > Without the trivial patch (in mono 2.6.4): > > Sorry but, what trivial patch are you referring to? > > > and the input in the upstream bug makes it clear, > > upstream is *unwilling* to fix it. > > > > No change (from my last comment) about the libtool part. > > It may not be a big problem (hard to tell), but it still is incorrect. > > > > Have you reported this second problem to upstream? > Ping ;-) I've got reasons to believe, that would be pointless (one of them are comments 9-10 in the upstream bug). I called patch "trivial" cause it's the change they've made in 64bit - the default one in our TEXREL guide. OK, we will then follow upstream decision on this, thanks for your work OK, though for me, it seems that decision was "we know it's broken and we don't give a ****". *** Bug 377645 has been marked as a duplicate of this bug. *** |