It seems that nobody actually read the full emerge log of this package. I did it only after investigating compatibility of mono 1.9.1 (ebuild from bug 213381) with libtool 2.2. There was a line there: ./configure: line 2846: ./libtool: No such file or directory the catch is it was there even for 1.5 series, cause they try to call libtool before calling AM_PROG_LIBTOOL. They need generated libtool twice during configure, but: 1. the first time they do a check (this one always fails, as it's before AM_PROG_LIBTOOL) that's similar to the one gtk+ does and one of the mail on the libtool mailing list suggests that they should have been able to do a simpler check, that does not require generating libtool even in 1.5 series this check, if correctly done, would add -Wl,--export-dynamic in a few places (at least for linux) 2. second time is not only surrounded by if test x$platform_win32 = xyes; ... fi but also looks like some silly hack, I can't tell if it was needed in the first place, somebody should ask either mono or libtool team what exactly that one does and whether it's really needed (with 1.5 and 2.2); I don't think it will affect anybody here anyway Actually, I think they're hacking around a bug in their own configure.in As a final issue, this time not libtool-related, as I don't fully understand mono' build system, I don't know what is the effect of having: touch "${S}"/mcs/build/deps/use-monolite in the ebuild, but for it to have any effect it should have been: mkdir "${S}"/mcs/build/deps && touch "${S}"/mcs/build/deps/use-monolite
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. ***
