Bump to mono:2019-06 #3155
Bump to mono:2019-06 #3155
Conversation
directhex
added
the
full-mono-integration-build
|
This currently fails while trying to build This is kinda weird in that Equally odd is that a subsequent compile for Seems that the netstandard2.0 build is failing? |
|
This might be a reason to "bite the bullet" and "binary rename" |
|
For comparison/reference, if I locally bump Java.Interop/external/cecil to https://github.com/mono/cecil/tree/a6c8f5e1070d25c38cbfaa415d6f6853e5236687, cecil builds without error when using mono 6.0.0.6. # in Java.Interop
$ git clean -xdf
$ make prepare JI_MAX_JDK=8
$ (cd external/cecil ; git checkout a6c8f5e1070d25c38cbfaa415d6f6853e5236687)
$ make all
$ find bin -iname \*Cecil\*
...
bin/Debug/Xamarin.Android.Cecil.dll
...If I try the same steps using mono 6.4.0.0, it fails! # ...same as above...
$ make all V=1
...
Building target "GenerateBuildDependencyFile" completely.
Output file "/Users/jon/Dropbox/Developer/Java.Interop/bin/Debug/netstandard2.0/Java.Interop.deps.json" does not exist.
Using "GenerateDepsFile" task from assembly "/usr/local/share/dotnet/sdk/2.1.505/Sdks/Microsoft.NET.Sdk/targets/../tools/net46/Microsoft.NET.Build.Tasks.dll".
Task "GenerateDepsFile"
/usr/local/share/dotnet/sdk/2.1.505/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(129,5): error MSB4018: The "GenerateDepsFile" task failed unexpectedly.
/usr/local/share/dotnet/sdk/2.1.505/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(129,5): error MSB4018: System.MissingMethodException: Method not found: System.Collections.Generic.IList`1<NuGet.Packaging.Core.PackageDependency> NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies()
...Looks like our favorite If I "move" Fun! |
|
For additional "giggles", this appears to be an msbuild problem. As luck would have it, installing cd /Library/Frameworks/Mono.framework/Versions/6.4.0/lib/mono
sudo mv msbuild msbuild-6.4.0
sudo ln -s /Library/Frameworks/Mono.framework/Versions/6.0.0/lib/mono/msbuild .So now I have msbuild 16.0.42-preview+g804bde742b (mono 6.0.0.6) instead of 16.0.457+g4e8391a0f3 (mono 6.4.0.0), while the rest of Result? |
Context: #3155 The original attempt at bumping to mono/mono@da1fa28 is failing largely because the updated system mono 6.4.0 won't build the xamarin-android and Java.Interop repo's, seemingly because of new [issues within msbuild][0]. # within Java.Interop make all V=1 ... Building target "GenerateBuildDependencyFile" completely. Output file "/Users/jon/Dropbox/Developer/Java.Interop/bin/Debug/netstandard2.0/Java.Interop.deps.json" does not exist. Using "GenerateDepsFile" task from assembly "/usr/local/share/dotnet/sdk/2.1.505/Sdks/Microsoft.NET.Sdk/targets/../tools/net46/Microsoft.NET.Build.Tasks.dll". Task "GenerateDepsFile" /usr/local/share/dotnet/sdk/2.1.505/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(129,5): error MSB4018: The "GenerateDepsFile" task failed unexpectedly. /usr/local/share/dotnet/sdk/2.1.505/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(129,5): error MSB4018: System.MissingMethodException: Method not found: System.Collections.Generic.IList`1<NuGet.Packaging.Core.PackageDependency> NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies() ... In an attempt to expedite the bump, or at minimum see what other problems befall us, *drop* the system mono bump -- sticking with mono 6.0.0.6 for builds -- and *just* bump the mono submodule. This should allow the on-device tests to execute. [0]: #3155 (comment)
|
Since the current problems with this PR is that things can't even build with the updated Let's see if that fares any better. |
|
the |
|
Apparently, the problem is that the dotnet SDK is "too old":
Part of the fix is to stop using such an old version of the dotnet SDK. We need to ensure that dotnet 2.1.700 or later is installed, if any version is installed. |
Changes: dotnet/java-interop@fd77553...94b9551 * `JniFieldInfo.ToString()` and `JniMethodInfo.ToString()` shouldn't throw a `NotSupportedException`. * Migrate `src/java-interop` to C++ * Restore `Mono.Cecil.sln` before attempting to build * Alter how we override `Xamarin.Android.Cecil.dll` in Cecil's build Context: #3155 One of the problems encountered while attempting to bump to use mono/2019-06 (PR #3155) is that Cecil failed to build, and Cecil failed to build because `Mono.Cecil.sln` wasn't being restored before we built it (because it wasn't previously required). Bump to a Java.Interop which adds support for restoring `Mono.Cecil.sln`, fixing the above build problem, and deal with all the other assorted "breakage" that Java.Interop introduced as part of the C++ migration.
Also do not set the CecilRestoreConfiguration as the default value should work OK with mono/2019-06 and its cecil.
Also do not set the CecilRestoreConfiguration as the default value should work OK with mono/2019-06 and its cecil.
* mono-2019-06: Changing configuration to reference the right mono version after a mono bump Also update the Azure artefacts link to match the mono hash Rebase on master and bump mono Bump to mono:2019-06
Mono 2019 06 xaprepare
|
@radekdoulik See #3155 (comment) re: the API breaking changes. |
|
@steveisok for the API changes, the comment you mentioned explains only the extension methods location change. It doesn't explain the 2 removed types and the removed constructor. What is the story about those? Is it a regression? |
|
@radekdoulik the removed ctor is also a dotnet/standard driven change. |
|
OK, so the constructor is this issue: dotnet/standard#1171 and was done intentionally in mono. I will check whether the remaining types are really removed. |
|
@steveisok @EgorBo So the types were removed from the |
|
Both CryptographicOperations and FileSystemName are new types in .NET Standard 2.1. They were part of .NET Core before and made it into mono from there, but weren't in any shipping version of NS. I'm not sure whether we added typeforwarders for similar cases before. |
@radekdoulik, I managed to reproduce it and here's the fix/workaround. The issue comes from CppSharp's lack of knowledge about the int ioctl(int __fd, int __request, ...);
#if !defined(BIONIC_IOCTL_NO_SIGNEDNESS_OVERLOAD)
/* enable_if(1) just exists to break overloading ties. */
int ioctl(int __fd, unsigned __request, ...) __overloadable __enable_if(1, "") __RENAME(ioctl);
#endif
#define __RENAME(x) __asm__(#x)The real fix would have to be to make |
|
@steveisok @EgorBo @akoeplinger I have checked both types and the https://raw.githubusercontent.com/xamarin/xamarin-android-api-compatibility/d16-1/reference/System.xml already contains The other one, |
|
OTOH, the types are still present in |
|
The latest mono bump has the type forwards and should resolve the ConnectWithNoEncryption test |
Mono has just dropped the llvm32 cross compilers because it is now possible to cross compile to 32-bit using the 64-bit compiler. Remove requirement for 32-bit llvm runtime in preparation stage.
3 extension methods extracted from `System.Threading.Tasks.TaskExtensions` to a new `System.Threading.Tasks.TaskAsyncEnumerableExtensions` class. They stay in the same namespace and being extension methods, they should not break anything. public static System.Runtime.CompilerServices.ConfiguredCancelableAsyncEnumerable<T> ConfigureAwait<T> (this System.Collections.Generic.IAsyncEnumerable<T>, bool); public static System.Runtime.CompilerServices.ConfiguredAsyncDisposable ConfigureAwait (this System.IAsyncDisposable, bool); public static System.Runtime.CompilerServices.ConfiguredCancelableAsyncEnumerable<T> WithCancellation<T> (this System.Collections.Generic.IAsyncEnumerable<T>, System.Threading.CancellationToken); Context: dotnet/standard@ebeec50#diff-93ef3714cd10edf17d6d8045cf3406b8, dotnet/android#3155 (comment)
To get API changes for *2019-06*, namely the `System.ComponentModel.BaseNumberConverter` removal and `System.Threading.Tasks.TaskExtensions` methods extraction/move.
System.IO.Enumeration.FileSystemName and
System.Security.Cryptography.CryptographicOperations classes were
removed from System.xml as they were duplicates of mscorlib ones. They
were removed as part of NS2.1 work in mono.
They were added by mistake and removed later. Because they were
already present in 16.1 and 16.2 respectively, mono team added type
forwarders to `System.dll` to avoid/lessen API breakage.
System.dll now contains:
.class extern forwarder System.IO.Enumeration.FileSystemName
{
.assembly extern mscorlib
}
.class extern forwarder System.Security.Cryptography.CryptographicOperations
{
.assembly extern mscorlib
}
Context:
mono/mono@ba719ac
dotnet/android#3155 (comment)
To have it aware about the removed `System.IO.Enumeration.FileSystemName` and `System.Security.Cryptography.CryptographicOperations` classes.
To get "[2019-06] Fix offsets tool for Android NDK r20 (#15650)"
|
The jenkins tests are green, azure test has less fails than master => ready to merge. I am just going to reset the tests timeout values and merge. |
To be on par with master branch
|
It turned out some of the submodules were on lower versions than master, so I reset the timeouts and updated the submodules. Let see if the submodule bumps didn't break anything. |
Bump to mono/2019-06 branch and set mono required versions. [cecil] Fix the cecil build by reverting "Add a solution file for remap-assembly-ref (#3248)" Using the solution instead of csproj broke the cecil build. I didn't traced all the details, but we ended up with compiling `Mono.Cecil.dll` without any references. Use 7z when downloading Mono Archives [xaprepare] Drop llvm32 cross compilers Mono has just dropped the llvm32 cross compilers because it is now possible to cross compile to 32-bit using the 64-bit compiler. Remove requirement for 32-bit llvm runtime in preparation stage. [tests] Updated Xamarin.Android.Net tests Update Properties_Invalid test to reflect current implementation This was testing part of our old HttpClientHandler implementation introduced here: mono/mono@f97e03f The current corefx implementation doesn't throw when `UseProxy` is false. The documentation doesn't specify such behavior, so I assume it was specific for our old implementaion. Context: https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.proxy?view=netframework-4.8 https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.useproxy?view=netframework-4.8 https://github.com/mono/corefx/blob/9354dfd8d3cd4af62592bee9d8fe434e5694788a/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs#L242 https://github.com/mono/corefx/blob/9354dfd8d3cd4af62592bee9d8fe434e5694788a/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/SocketsHttpHandler.cs#L75 https://github.com/mono/corefx/blob/9354dfd8d3cd4af62592bee9d8fe434e5694788a/src/System.Net.Http/src/System/Net/Http/CurlHandler/CurlHandler.cs#L234 Remove broken HttpClient test Context: #3155 (comment) [linker] Disable linker's UnreachableBodies optimization Disable it for now til we find out a fix. Context: #3202 [jnimarshalmethod-gen] Introduce MonoAndroidLibDirectory property As we have switched to dynamically linker mono recently, we need to have libmonosgen in dyld path. So we set `DYLD_LIBRARY_PATH` for `mono` when running `jnimarshalmethod-gen` [tests] Exclude network tests which hang. Context: mono/mono#14938 Context: dotnet/macios#6228 [xamarin-android-api-compatibility] API changes System.IO.Enumeration.FileSystemName and System.Security.Cryptography.CryptographicOperations classes were removed from System.xml as they were duplicates of mscorlib ones. They were removed as part of NS2.1 work in mono. They were added by mistake and removed later. Because they were already present in 16.1 and 16.2 respectively, mono team added type forwarders to `System.dll` to avoid/lessen API breakage. System.dll now contains: .class extern forwarder System.IO.Enumeration.FileSystemName { .assembly extern mscorlib } .class extern forwarder System.Security.Cryptography.CryptographicOperations { .assembly extern mscorlib } Context: mono/mono@ba719ac #3155 (comment) 3 extension methods extracted from `System.Threading.Tasks.TaskExtensions` to a new `System.Threading.Tasks.TaskAsyncEnumerableExtensions` class. They stay in the same namespace and being extension methods, they should not break anything. public static System.Runtime.CompilerServices.ConfiguredCancelableAsyncEnumerable<T> ConfigureAwait<T> (this System.Collections.Generic.IAsyncEnumerable<T>, bool); public static System.Runtime.CompilerServices.ConfiguredAsyncDisposable ConfigureAwait (this System.IAsyncDisposable, bool); public static System.Runtime.CompilerServices.ConfiguredCancelableAsyncEnumerable<T> WithCancellation<T> (this System.Collections.Generic.IAsyncEnumerable<T>, System.Threading.CancellationToken); Context: dotnet/standard@ebeec50#diff-93ef3714cd10edf17d6d8045cf3406b8 #3155 (comment)
Bump to mono/2019-06 branch and set mono required versions.
[cecil] Fix the cecil build by reverting "Add a solution file for remap-assembly-ref (#3248)"
Using the solution instead of csproj broke the cecil build. I didn't
traced all the details, but we ended up with compiling
Mono.Cecil.dllwithout any references.Use 7z when downloading Mono Archives
[xaprepare] Drop llvm32 cross compilers
Mono has just dropped the llvm32 cross compilers because it is now possible to
cross compile to 32-bit using the 64-bit compiler.
Remove requirement for 32-bit llvm runtime in preparation stage.
[tests] Updated Xamarin.Android.Net tests
Update Properties_Invalid test to reflect current implementation
This was testing part of our old HttpClientHandler implementation
introduced here:
mono/mono@f97e03f
The current corefx implementation doesn't throw when
UseProxyisfalse. The documentation doesn't specify such behavior, so I assume it
was specific for our old implementaion.
Context:
https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.proxy?view=netframework-4.8
https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.useproxy?view=netframework-4.8
https://github.com/mono/corefx/blob/9354dfd8d3cd4af62592bee9d8fe434e5694788a/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs#L242
https://github.com/mono/corefx/blob/9354dfd8d3cd4af62592bee9d8fe434e5694788a/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/SocketsHttpHandler.cs#L75
https://github.com/mono/corefx/blob/9354dfd8d3cd4af62592bee9d8fe434e5694788a/src/System.Net.Http/src/System/Net/Http/CurlHandler/CurlHandler.cs#L234
Remove broken HttpClient test
Context: #3155 (comment)
[linker] Disable linker's UnreachableBodies optimization
Disable it for now til we find out a fix.
Context: #3202
[jnimarshalmethod-gen] Introduce MonoAndroidLibDirectory property
As we have switched to dynamically linker mono recently, we need to have
libmonosgen in dyld path. So we set
DYLD_LIBRARY_PATHformonowhen running
jnimarshalmethod-gen[tests] Exclude network tests which hang.
Context: mono/mono#14938
Context: dotnet/macios#6228
[xamarin-android-api-compatibility] API changes
System.IO.Enumeration.FileSystemName and
System.Security.Cryptography.CryptographicOperations classes were
removed from System.xml as they were duplicates of mscorlib ones. They
were removed as part of NS2.1 work in mono.
They were added by mistake and removed later. Because they were
already present in 16.1 and 16.2 respectively, mono team added type
forwarders to
System.dllto avoid/lessen API breakage.System.dll now contains:
Context:
mono/mono@ba719ac
#3155 (comment)
3 extension methods extracted from
System.Threading.Tasks.TaskExtensionsto a newSystem.Threading.Tasks.TaskAsyncEnumerableExtensionsclass.They stay in the same namespace and being extension methods, they
should not break anything.
Context:
dotnet/standard@ebeec50#diff-93ef3714cd10edf17d6d8045cf3406b8
#3155 (comment)