I am tired of those "mono upgrade problem ? please re-install it"; let me create a solution bug: if your bug has been marked duplicate of this one, this means the solution (that is not a fix) for your problem is simple: *** emerge -C mono ; emerge -va1 mono *** END No need to comment life time this bug; this bug (will) holds a list of bugs for which this solution works (I remind: a solution may not be a fix) so that maint of Gentoo can quikly close new bugs, and maints of Mono can have a list of problems and reports about it. Good luck every body, and happy emerge -C :)
/me notes that this is not a (proper) solution. Shrug...
doing as for http://bugs.gentoo.org/show_bug.cgi?id=122774
*** Bug 146301 has been marked as a duplicate of this bug. ***
*** Bug 154672 has been marked as a duplicate of this bug. ***
*** Bug 155066 has been marked as a duplicate of this bug. ***
*** Bug 156610 has been marked as a duplicate of this bug. ***
*** Bug 156854 has been marked as a duplicate of this bug. ***
Do you think we could partially solve the problem doing this in ebuild: - we leave download/extract/configure steps as are - copy /usr/include in temp/work directory - do a symbolic link to the root of work dir, from ${WORKDIR}/${WORKDIR} - do the make/compile in some chroot I am not to force unemerge before compile (what if compile fails ? no more mono at all for users ???). If mono is bothered with installed version, this should help him about this. If not enough, then we move configure in chroot, but then, we also have to copy loads of tools (automake, autoconf, make ...). I know this sounds very heavy work; I just intend to get emerge stop "stopping" on mono every upgrade. What do you all think about chroot ? (If some maints comes around, please close open bugs 124225 126691 127066 and 131569 . Or if you dont, tell me why not. Thanks. )
*** Bug 131569 has been marked as a duplicate of this bug. ***
*** Bug 157969 has been marked as a duplicate of this bug. ***
*** Bug 160889 has been marked as a duplicate of this bug. ***
*** Bug 162548 has been marked as a duplicate of this bug. ***
*** Bug 167357 has been marked as a duplicate of this bug. ***
there is a little flow in that solution. When it comes to upgrade of an important system package (i.e. glibc) there 'emerge -e system' is needed. In that case mono wont'ge upgraded so we have to emerge --resume --skip-first to skip mono and conitnue that -e battle. To be sure that we have our software linked against newer mono wehave to upgrade mono first, then emerge -e (system|world) I know that is not common but it is, well, important to have it mentioned sometimes.
(In reply to comment #14) > there is a little flow in that solution. emerge -C is not proposed as a fix but as a workaround ! This bug tracks dups. Of course you are right in a way ... and THE SOLUTION would be to fix the code ;) By definition, the simple fact "this bug" is open DOES mean there is a "problem". So, yes we know there may be cases where this problem have potentially very big impact. That's why this bug is tagged NEW, and not CLOSED ;) If you are brave enough, please submit a patch :)
Since some months ago (I think that 4 or 5) I always install mono (and mono releated packages) from testing and the problem dissappeared for me. Is possible that an updrate from 1.1.16.1 to 1.2.2.1 fails with this problem but, an upgrate from 1.2.0 to newer versions work fine for me
*** Bug 179835 has been marked as a duplicate of this bug. ***
I think most of these problems will be solved by forcing the build to run in the C or POSIX locales.
For last few days I tried to solve that issue by preventing mcs from accessing system-wide GAC in /usr/lib/mono/gac. When mono is not installed, I18N.dll is not being found: open("/usr/lib/mono/gac/policy.2.0.I18N/0.0.0.0__0738eb9f132ed756/policy.2.0.I18N.dll", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N.dll", 0xbfeccb78) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N.exe", 0xbfeccb78) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N/I18N.dll", 0xbfeccb78) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N/I18N.exe", 0xbfeccb78) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N.dll", 0xbfeccb78) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N.exe", 0xbfeccb78) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N/I18N.dll", 0xbfeccb78) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N/I18N.exe", 0xbfeccb78) = -1 ENOENT (No such file or directory) open("/usr/lib/mono/gac/I18N/2.0.0.0__0738eb9f132ed756/I18N.dll", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/I18N.dll", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/mono/gac/I18N/2.0.0.0__0738eb9f132ed756/I18N.exe", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/usr/lib/I18N.exe", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) and everything goes on smoothly. However, when there is a copy of I18N.dll in system-wide gac: open("/usr/lib/mono/gac/policy.2.0.I18N/0.0.0.0__0738eb9f132ed756/policy.2.0.I18N.dll", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N.dll", 0xbfabf768) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N.exe", 0xbfabf768) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N/I18N.dll", 0xbfabf768) = -1 ENOENT (No such file or directory) stat64("/var/tmp/portage/dev-lang/mono-1.2.4/work/mono-1.2.4/mcs/class/lib/net_2_0_bootstrap/I18N/I18N.exe", 0xbfabf768) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N.dll", 0xbfabf768) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N.exe", 0xbfabf768) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N/I18N.dll", 0xbfabf768) = -1 ENOENT (No such file or directory) stat64("../../class/lib/net_2_0_bootstrap/I18N/I18N.exe", 0xbfabf768) = -1 ENOENT (No such file or directory) open("/usr/lib/mono/gac/I18N/2.0.0.0__0738eb9f132ed756/I18N.dll", O_RDONLY|O_LARGEFILE) = 6 the file is found - last open(...) returns a correct file descriptor, then the build process fails. Are you sure that resetting LANG and LC_ALL to C or POSIX before building will not affect further using mono and its I18N functionality?
The locale used to build Mono should have no effect on the result of the build. As far as the C# compiler goes, we specify the appropriate codepage for each source file, and I think we always use the "invariant culture" for case-insensitive compares. If there's an problem, it's a bug in mono :-) --- As to the problem of the missing/present I18N.dll -- older mono runtimes exited when dlls were not found, newer ones throw exceptions which can be caught and ignored: that could explain why the build sometimes fails and sometimes passes with a missing I18N.dll.
The mono packager for Debian also faced a similar issue, and the Debian build scripts have been using LC_ALL=C since Oct 2006. Their build line, according to http://svn.debian.org/wsvn/pkg-mono/mono/trunk/debian/rules?op=file&rev=0&sc=0 LC_ALL=C $(MAKE) EXTERNAL_MCS=false EXTERNAL_MONO=false This is based on: http://lists.alioth.debian.org/pipermail/pkg-mono-devel/2006-October/000548.html
I confirm, this solution works. Excellent! Thank you for your contribution, Raja, we really appreciate it! Fixed ebuilds have already been commited to the tree, so I'm finally closing this and all related bugs.
*** Bug 127066 has been marked as a duplicate of this bug. ***
*** Bug 162214 has been marked as a duplicate of this bug. ***
