Bugzilla Bug 146424

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. ***