lang/mono: Update to 5.10.1.47

[feld]

Summary

Update our mono to a modern version. The one in ports currently is an
early release of the 5.x branch and is very buggy. I see lots of crashes
that never used to happen with 4.8.

This version builds and packages and is using BoringSSL

TODO:

• Enable jemalloc from base if possible edit: I think the jemalloc from base is already used and compiling in jemalloc support is not necessary
• Tests?
• Figure out if any of the old patches from D14006 are worth keeping
  • I removed all of those patches after conferring with the guy who ported Mono to AIX recently and something in there was also causing failures. edit: some patches have been resurrected

Also he strongly recommends against us trying to make "freebsd" verb a
supported platform. Even his AIX builds piggyback on the "linux" verb.
It seems to cause needless complexity. (I might be using wrong
terminology here; I don't grok build frameworks very well)

I also have a patch that fixes an issue with freebsd building with a
newer version of corefx, but that seems to only occur if we try to build
mono HEAD.

This has changed from the mono 5.12 release to mono 5.10 release due to compatibility issues found with mono 5.12

Test Plan

Group Reviewers: mono

[feld]

Upload correct copy of the pkg-plist

[feld]

Revive some patches, pass testport (leftovers from cert store)

[feld]

Add comment about where GH_TUPLE versions came from

[mat]

lang/mono/Makefile

20

No, never. USES=python is enough.

[feld]

USES=python does not provide /usr/local/bin/python. There are countless places in the build system that call "python" instead of "python2.7" (not shebangs) and I couldn't possibly patch them all just to get this to build. What alternative do we have?

[mat]

In D15780#333772, @feld wrote:

USES=python does not provide /usr/local/bin/python. There are countless places in the build system that call "python" instead of "python2.7" (not shebangs) and I couldn't possibly patch them all just to get this to build. What alternative do we have?

BINARY_ALIAS=  python=${PYTHON_CMD}

5.17. Use BINARY_ALIAS to Rename Commands Instead of Patching the Build

[feld]

In D15780#333783, @mat wrote:

In D15780#333772, @feld wrote:

USES=python does not provide /usr/local/bin/python. There are countless places in the build system that call "python" instead of "python2.7" (not shebangs) and I couldn't possibly patch them all just to get this to build. What alternative do we have?

BINARY_ALIAS=  python=${PYTHON_CMD}

5.17. Use BINARY_ALIAS to Rename Commands Instead of Patching the Build

Thank you for showing me this! I did not realize we gained this capability.

[feld]

I'm seeing a few issues with my mono apps I am testing. After speaking with a developer he strongly suggests we follow the "very stable" release which is what they ship with Visual Studio for Mac. That would be slightly older version 5.10.1.47. I will see if I can get it building and if it passes my requirements I will adjust this review to target that release instead. I'd really like us to have a very stable release of mono to rely on. If we need a separate port for people who want the absolute latest version we could do it.

[feld]

Switch to the "really stable" release: 5.10.1.47

This release seems to be working with all of my mono-based apps

[feld]

Disable USES=display by default. Only used for tests, can hide behind X11 option for now.

[dbn]

In D15780#333902, @feld wrote:

Disable USES=display by default. Only used for tests, can hide behind X11 option for now.

I think there is a USES=display:test that should be used in conjunction with X11

[dbn]

I have been working on an update and I think some of the changes in that patch [1] will be useful. Given that your tests are all passing I suggest we go with your version. I do however see the latest version is 5.10.1.57 (but mono versioning just confuses me).

Some useful changes in my patch [1] that I think will be of use include:

• Updating mono-basic: the bootstrap compiler does not run with newer versions of mono
• Patching gtk-sharp30: changes in the mono profiler API require this change
• Dropping GitHub: GitHub was originally used to get full test suite coverage, however acceptance tests were never working, and I see the source tarball now includes many (all?) tests. It just makes updating a lot easier.
• Add ODBC dependency: required by System.Data

I was surprised to see that we can use the linux version of monolite. My understanding is that there is specific OS code that gets included per "verb". I had also added freebsd as a "verb", but you say it works with "linux" for you... I'll track down some freebsd specific code and see if it really does differ to linux (e.g. kqueue/kevent).

I'll happily run an exp-run for you. The exp-run for patch [1] is at [2] (note it was a cumulative exp-run, all other ports depending on mono had succeeded in previous builds).

If there is anything else I can do to help, please let me know.

[1] https://people.freebsd.org/~dbn/mono.diff
[2] http://dbn.westeurope.cloudapp.azure.com/mono.html

[feld]

In D15780#333908, @dbn wrote:

In D15780#333902, @feld wrote:

Disable USES=display by default. Only used for tests, can hide behind X11 option for now.

I think there is a USES=display:test that should be used in conjunction with X11

I'm currently using

X11_USES=       display

for this. I think the framework is bugged here because display:test causes it to build the X11 components always even when you're not running "make test".

[feld]

In D15780#333909, @dbn wrote:

I have been working on an update and I think some of the changes in that patch [1] will be useful.

I will take any improvements you have available! :)

Given that your tests are all passing I suggest we go with your version.

I have not confirmed tests are all passing. This may be a misunderstanding.

I do however see the latest version is 5.10.1.57 (but mono versioning just confuses me).

After conferring with some others, it was suggested that for best reliability we should track the releases used by Visual Basic found here http://www.mono-project.com/download/vs/ as they get more thorough testing.

Some useful changes in my patch [1] that I think will be of use include:

• Updating mono-basic: the bootstrap compiler does not run with newer versions of mono

I'll go with your gut instinct here.

• Patching gtk-sharp30: changes in the mono profiler API require this change

Ahh, good to know

• Dropping GitHub: GitHub was originally used to get full test suite coverage, however acceptance tests were never working, and I see the source tarball now includes many (all?) tests. It just makes updating a lot easier.

Simple, agreed.

• Add ODBC dependency: required by System.Data

Sounds good as well.

I was surprised to see that we can use the linux version of monolite. My understanding is that there is specific OS code that gets included per "verb". I had also added freebsd as a "verb", but you say it works with "linux" for you... I'll track down some freebsd specific code and see if it really does differ to linux (e.g. kqueue/kevent).

Even the AIX platform uses the linux version of monolite. I've been told it has no specific OS code, so this confuses me as well.

I'll happily run an exp-run for you. The exp-run for patch [1] is at [2] (note it was a cumulative exp-run, all other ports depending on mono had succeeded in previous builds).

Please and thanks! Let's finish polishing this and get the exp-run completed.

If there is anything else I can do to help, please let me know.

[1] https://people.freebsd.org/~dbn/mono.diff
[2] http://dbn.westeurope.cloudapp.azure.com/mono.html

[feld]

The analyzed output of "make tests" seems to indicate we are passing them all. They reported results look like this:

Results: total tests: 22, all pass

The lines say "all pass" with varying numbers of tests.

[feld]

More changes as suggested by dbn

[dbn]

1. Exp-run started: http://dbn.westeurope.cloudapp.azure.com/mono.html
   • Known issues are games/openar and devel/nant
   • games/openar: periodic failures (likely build concurrency issue)
   • devel/nant: does not build on FreeBSD-12 on a FreeBSD-11 kernel
2. I had difficulty applying your patch regarding the eglib patch files (there is a duplicate entry for the patches).
3. I did find some OS specific code in System.Data [a], although the build system only included a Unix generic file [b]. So I think we are good to go without changing the build system.
4. This update fixes PR 211367

a) external/corefx/src/Common/src/Interop/
b) mcs/class/System.Data/linux_net_4_x_System.Data.dll.sources

[feld]

For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

[dbn]

Exp-run done and a few new failures (see [1]). I think you need to restore the following patches:

• patch-mcs_tools_xbuild_data_12.0_Microsoft.CSharp.targets
• patch-mcs_tools_xbuild_data_14.0_Microsoft.CSharp.targets

It would help with my exp-run if you bump PORTREVISION. I can then do an incremental exp-run, which will save ~4 hours in turnaround time.

[1] http://dbn.westeurope.cloudapp.azure.com/mono.html

[feld]

Restoring patches and bumping PORTREVISION for dbn exp-run

[dbn]

In D15780#334798, @feld wrote:

For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

I see mono has 4 "channels": nightly, preview, stable and visual studio. This release, as you have indicated, is the latest on the visual studio channel. I agree that we proceed with this release and that we stick with the visual studio (hopefully less updates and more stability).

[dbn]

! In D15780#334798, @feld wrote:
For the record, I found a bug related to HTTP headers with my apps that I was able to reproduce with Mono 5.10, so my apps that were "failing" with 5.12 might not have been a 5.12 issue but something else in the 5.x train that caused it. I'd rather we push this out the barn door before 2018Q3 and then we can look at 5.12 in ports again. It should be much easier to upgrade now.

To actually address the HTTP headers issue, there is a known issue with FreeBSD and a newer implementation of System.Net.Http in dotnet core. Since mono is now sharing a lot of code from dotnet core this may have come over as well. Worth investigating a bit...

See this [1] issue on GitHub, specifically search for DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER. I think the exact issue was discussed in another issue but I cannot find that one.

[1] https://github.com/dotnet/coreclr/issues/18067

[dbn]

exp-run successful, please commit :-D

[mat]

Side note, you may want to read Chapter 15. Order of Variables in Port Makefiles to reorder the Makefile.

head/lang/mono/Makefile

8–9 ↗

(On Diff #43903)

Remove the :mono from here, not needed.