-
Notifications
You must be signed in to change notification settings - Fork 565
Bump to mono/2017-10/63e8dc6e #1112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Doubly weird here is that it built on macOS+msbuild, but failed to build on macOS+xbuild. The only difference between those environments should be around whether unit tests are executed, not the build itself. Very puzzling. :-( I've restarted the macOS+xbuild build. Let's see if Take 2 fairs any better. |
Different machines. Because of course it's some form of machine/environment difference. The passing macOS+msbuild build was on |
|
This should fix the build mono/mono#6260. The failure is caused by: |
|
The underlying cause of the failure is actually PR #1105 (!). The |
|
As with PR #1101, there are 98 unit test failures. This requires further investigation. For starters, what about a smaller test case? :-) # assume a complete xamarin-android build...
$ make prepare all
$ cd samples/HelloWorld
$ ../../bin/Debug/bin/xabuild /p:Configuration=Release /p:BundleAssemblies=True /p:TargetFrameworkVersion=v8.1 /v:diag > b.txtFortunately, it fails: This matches e.g. the Xamarin.Android.Build.Tests.BuildTest.BuildMkBundleApplicationRelease / Debug error, so we're on the right track. Reading the build log, this seems odd:
The contents of The We can thus conclude that, for whatever reason, the To validate this conclusion, if we use a stable Xamarin.Android: $ xbuild /p:Configuration=Release /p:BundleAssemblies=True /p:TargetFrameworkVersion=v8.0 /v:diag > b.txtThen the file |
|
As an educated shot-in-the-dark, I suspect that the linker bump within mono/2f18e7dd is responsible. If I leave the Fortunately there are only 14 commits in the linker bump. One manual "bisect" later, and the breakage appears to be due to linker/4d2362d8. Looking at that commit...it's not immediately apparent why that commit breaks things, but the preceding commit -- linker/7904df9f -- works as desired. Some manual testing later, and the cause is this line: @@ -247,7 +253,7 @@ namespace Mono.Linker {
} else if (IsCore (name)) {
action = _coreAction;
} else {
- action = AssemblyAction.Link;
+ action = _userAction;
}Revert that one line, so that |
Commit 4d2362d [broke the xamarin-android linker][0], as assemblies which should have been linked were no longer being linked. [0]: dotnet/android#1112 (comment) The apparent cause is that before commit 4d2362d, the "default" action would be `AssemblyAction.Link`. Starting with 4d2362d, the default action was instead `AssemblyAction.Skip`, as `LinkContext._userAction` would be zero-initialized during construction, and `AssemblyAction.Skip` is the default (0) enum value. Set `AssemblyAction._userAction` in the constructor to `AssemblyAction.Link`, so that pre-4d2362d8 linker behavior is retained. This should allow the Xamarin.Android linker to work without further changes.
|
PR for fix: dotnet/linker#203 Unfortunately, xamarin-android/master doesn't build against linker/master, as files were moved: Looks like it's linker/10f4163f which kills us. :-( That said, my PR applies cleanly atop linker/404f7316, and if I rebuild $ (cd src/Xamarin.Android.Build.Tasks/ ; xbuild)
$ (cd samples/HelloWorld ; ../../bin/Debug/bin/xabuild /p:Configuration=Release /p:BundleAssemblies=True /p:TargetFrameworkVersion=v8.1 /v:diag > b.txt)The above results in no build errors. |
Bumps to cecil/mono-2017-10/76ffcdab. Bumps to linker/master/404f7316 Set the new [`LinkContext.UserAction` property][0] to `AssemblyAction.Link`, as the default value of `AssemblyAction.Skip` causes [98 unit tests to fail][1]. [0]: dotnet/linker@4d2362d [1]: https://jenkins.mono-project.com/job/xamarin-android-pr-builder/2264/testReport/
2f367a6 to
845816a
Compare
|
dotnet/linker#203 was rejected, so the correct fix is for Xamarin.Android to set the PR has been updated accordingly. |
Bumps to cecil/mono-2017-10/76ffcdab.
This is consistent with cba77e9, which hopefully means we won't get
the unit test failures seen in PR #1101.