Bug 201883 - lang/mono: Update to 4.0.3.19
Summary: lang/mono: Update to 4.0.3.19
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-mono (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-26 06:30 UTC by Anders Jensen-Waud
Modified: 2015-08-16 07:06 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (mono)


Attachments
Patch file (including plist) (63.23 KB, patch)
2015-07-26 06:30 UTC, Anders Jensen-Waud
no flags Details | Diff
Workaround for getcwd(3) returning NULL with errno set to 0. (279 bytes, patch)
2015-08-09 12:23 UTC, Romain Tartière
no flags Details | Diff
Tidy-up workaround patch (295 bytes, patch)
2015-08-09 14:00 UTC, Romain Tartière
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Jensen-Waud 2015-07-26 06:30:06 UTC
Created attachment 159230 [details]
Patch file (including plist)

Attached is a patch to update Mono 4.0.1 to 4.0.3.19 in Ports.
Comment 1 Marcin Cieślak 2015-08-09 11:30:20 UTC
Great, you might also want to have a look at

https://github.com/mono/mono/pull/1863

(filed as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200783)

which makes us free from /proc. This got merged into git master, maybe we
can ask Mono to backport this to 4.0.3 as well.

There is also https://github.com/mono/mono/pull/1860 to fix mono on systems without $TZ set.

There is also some work in progress in https://github.com/mono/mono/pull/1882 to improve checks against iconv, maybe we could even make it to use base system iconv.
Comment 2 Kurt Jaeger freebsd_committer freebsd_triage 2015-08-09 11:45:20 UTC
Build-tests on cur 93a 10x 10i are fine.
Comment 3 Romain Tartière freebsd_committer freebsd_triage 2015-08-09 12:20:37 UTC
Reviewing ATM (I had a previous version in the pipeline).

The patch contains some weird files…  Please double-check this when you submit a PR.

Also, why was the CPE information removed from the uses?

Lastly, I encounter a strange behavior when building the port form my "usual" directory: /usr/home/romain/Projects/FreeBSD/ports/lang/mono.  The problems ties down to getcwd(3) returing NULL with errno set to 0 when actually the passed buffer is too small.  Am I the only one suffering from this issue?
Comment 4 Romain Tartière freebsd_committer freebsd_triage 2015-08-09 12:23:08 UTC
Created attachment 159689 [details]
Workaround for getcwd(3) returning NULL with errno set to 0.

A minimal test program does not produce this incorrect behavior…  I guess something magic is happening.
Comment 5 Marcin Cieślak 2015-08-09 12:54:28 UTC
You certainly don't want || here because errno maybe set to something before the whole thing starts.

Your getcwd() fails because of some other reason ("make clean" done in the other window?)

The problem with this code is that it does not say anything meaningful in non-ERANGE case.

Can you check what it says in your case?

--- a/eglib/src/gfile-posix.c
+++ b/eglib/src/gfile-posix.c
@@ -175,6 +175,8 @@ g_get_current_dir (void)
                        s <<= 1;
                }
        } while (fail);
+       if (r == NULL)
+           perror("getcwd");
 
        /* On amd64 sometimes the bottom 32-bits of r == the bottom 32-bits of buffer
         * but the top 32-bits of r have overflown to 0xffffffff (seriously wtf getcwd
Comment 6 Romain Tartière freebsd_committer freebsd_triage 2015-08-09 12:57:48 UTC
Aleady tried: getcwd() returns NULL and errno = 0.  Ignoring the errno value and looping while getcwd() returns NULL increases the buffer size until the CWD fits and then everything is fine.

My guess is that the system getcwd(3) function is masked and replaced by some other code that has this incorrect behavior, but I could not check any further.
Comment 7 Kurt Jaeger freebsd_committer freebsd_triage 2015-08-09 13:27:56 UTC
Btw, build-tests for 4.0.3.20 were fine as well 8-}
Comment 8 Marcin Cieślak 2015-08-09 13:30:42 UTC
No, they are using original getcwd(3) but I don't see the case where getcwd(3) returns NULL AND errno = 0 - very strange! Anything special about your directory?
Comment 9 Romain Tartière freebsd_committer freebsd_triage 2015-08-09 13:57:11 UTC
I am using 4.0.3.20.

I build mono as a regular user from a subdir of this user's $HOME directory where the ports has been checked-out.

Without patching eglib, the build fails when building mscorlib.dll:


~~~
[...]
mkdir -p -- ../../class/lib/build/
MCS     [build] mscorlib.dll

Cannot determine the text encoding for the assembly location: X±/class/lib/basic/basic.exe
Please add the correct encoding to MONO_EXTERNAL_ENCODINGS and try again.
../../build/library.make:270: recipe for target '../../class/lib/build/mscorlib.dll' failed
gmake[9]: *** [../../class/lib/build/mscorlib.dll] Error 255
../../build/rules.make:143: recipe for target 'do-all' failed
gmake[8]: *** [do-all] Error 2
../build/rules.make:164: recipe for target 'all-recursive' failed
gmake[7]: *** [all-recursive] Error 1
build/rules.make:164: recipe for target 'all-recursive' failed
gmake[6]: *** [all-recursive] Error 1
Makefile:45: recipe for target 'profile-do--build--all' failed
gmake[5]: *** [profile-do--build--all] Error 2
Makefile:41: recipe for target 'profiles-do--all' failed
gmake[4]: *** [profiles-do--all] Error 2
Makefile:555: recipe for target 'all-local' failed
gmake[3]: *** [all-local] Error 2
gmake[3]: Leaving directory '/usr/home/romain/Projects/FreeBSD/ports/lang/mono/work/mono-4.0.3/runtime'
Makefile:522: recipe for target 'all-recursive' failed
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory '/usr/home/romain/Projects/FreeBSD/ports/lang/mono/work/mono-4.0.3'
Makefile:449: recipe for target 'all' failed
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory '/usr/home/romain/Projects/FreeBSD/ports/lang/mono/work/mono-4.0.3'
~~~

Notice the garbage at the beginning of the assembly location.
Comment 10 Romain Tartière freebsd_committer freebsd_triage 2015-08-09 14:00:25 UTC
Created attachment 159690 [details]
Tidy-up workaround patch

Only loop if the buffer is too short (normal case) or if getcwd(3) returned NULL and errno is still 0 (our unexpected condition); keep the initial behavior otherwise (likely to cause problems anyway).
Comment 11 Marcin Cieślak 2015-08-09 15:00:18 UTC
(In reply to Romain Tartière from comment #10)

Yeah, that's better - but I am very frustrated how we got there. Which FreeBSD  version are you using? I've been toying with mono on 10.1-STABLE without any such problems...
Comment 12 Romain Tartière freebsd_committer freebsd_triage 2015-08-09 16:00:48 UTC
(In reply to Marcin Cieślak from comment #11)

10-STABLE here too:

% uname -v
FreeBSD 10.2-PRERELEASE #21 r286362: Thu Aug  6 17:27:51 CEST 2015     root@marvin.blogreen.org:/usr/obj/usr/src/sys/MARVIN

Do you experience this problem on your system copying /usr/ports/lang/mono to some directory with a longer name?
Comment 13 Marcin Cieślak 2015-08-09 21:13:13 UTC
Just tried git mono in /home/saper/something/pretty/long/maybe/getcwd/breaks/this/way/who/knows/mono and everything worked fine (with mono git master), but eglib is pretty much the same.

It's quite older than yours, r283908.
Comment 14 Marcin Cieślak 2015-08-10 12:24:45 UTC
Did you try single stepping via this code and libc to see what actually happens?
Comment 15 Romain Tartière freebsd_committer freebsd_triage 2015-08-16 07:06:57 UTC
Forgot to link r394390 to this PR.(In reply to Marcin Cieślak from comment #14)
My time constraints do not allow me to do this soon.

I have committed my update to 4.0.3.20 as r394390.