Skip to content
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

64 bit cross compilers targeting 32 bit platforms #9621

Closed
marek-safar opened this issue Jul 18, 2018 · 4 comments
Assignees
Labels

Comments

@marek-safar
Copy link
Member

@marek-safar marek-safar commented Jul 18, 2018

We'll have to come up with a solution to update Mono cross-compilers to handle the bitness difference, i.e. generate 32bits code from a 64bits process.

The main motivation is because Apple is planning to remove 32bits support from macOS.

This affects Xamarin.iOS tooling since the current Mono AOT cross-compiler needs to be an 32bits executable to produce 32bits code, e.g. ARMv7[s][k]. This is a problem because we’ll still require 32bits support for watchOS and iOS. The similar situation could happen with Android.

Apple confirmed that macOS 10.15 will not ship with 32bits slices of any system libraries. Running the watchOS simulator (and likely old iOS ones) will work since it is (or will be) shipped as a self-contained package (the 32bits libraries won’t be for macOS).

Milestone I

  • Update Mono sources where needed to have the configurable target size
  • Check the output binary is same when cross compiling as with 32 bits

Milestone II

  • Produce cross compiler output as part of SDK target for iOS
  • Produce cross compiler output as part of SDK target for Android

Milestone III

  • Figure out Xamarin.iOS integration
  • Figure out Xamarin.Android integration
  • switch to python offset tool.
@marek-safar marek-safar added the task label Jul 18, 2018
@marek-safar marek-safar added this to Backlog in Short Term Projects via automation Jul 18, 2018
@vargaz

This comment has been minimized.

Copy link
Member

@vargaz vargaz commented Jul 23, 2018

Short documentation:

  • any code which refers to host sizes/offsets and can influence generated code needs to use target sizes/offsets. I.e. sizeof(gpointer) should be sizeof(target_mgreg_t), etc.
  • code which depends on the sizes/offsets being the host ones like allocation, corlib version checks, need to be disabled.
@lewurm

This comment has been minimized.

Copy link
Member

@lewurm lewurm commented Mar 19, 2019

Related to this issue:

$ file Xamarin.iOS.framework/Versions/git/LLVM*/bin/llc
Xamarin.iOS.framework/Versions/git/LLVM/bin/llc:   Mach-O 64-bit executable x86_64
Xamarin.iOS.framework/Versions/git/LLVM36/bin/llc: Mach-O executable i386

Alternatively we could try to get rid of LLVM36.

@vargaz

This comment has been minimized.

Copy link
Member

@vargaz vargaz commented Mar 19, 2019

The 32 bit executables are not really needed, they are only there to simplify some build scripts.

@vargaz

This comment has been minimized.

Copy link
Member

@vargaz vargaz commented Mar 19, 2019

So now we have ios-cross32-64 targets in builds/. They should be drop-in replacements for the normal 32 bit cross compilers. Also, these cross compilers are used by wasm, so they are somehow tested.

@lewurm lewurm added this to the 2019-06 (6.4.xx) milestone Jun 6, 2019
lewurm added a commit to lewurm/mono that referenced this issue Jun 6, 2019
…r LLVM

Contributes to mono#9621
Fixes mono#14841

Note that it breaks iOS 32bit on devices. The Apple Watch _might_ still works (only tested on `2019-02`).  It unblocks some build related issues on the Xamarin.iOS `2019-06` integration, and we have to do it anyway. I'll come back to it to fix device related issues.
lewurm added a commit to lewurm/mono that referenced this issue Jun 6, 2019
…r LLVM

Contributes to mono#9621
Fixes mono#14841

Note that it breaks iOS 32bit on devices. The Apple Watch _might_ still works (only tested on `2019-02`).  It unblocks some build related issues on the Xamarin.iOS `2019-06` integration, and we have to do it anyway. I'll come back to it to fix device related issues.
lewurm added a commit to lewurm/mono that referenced this issue Jun 6, 2019
…r LLVM

Contributes to mono#9621
Fixes mono#14841

Note that it breaks iOS 32bit on devices. The Apple Watch _might_ still works (only tested on `2019-02`).  It unblocks some build related issues on the Xamarin.iOS `2019-06` integration, and we have to do it anyway. I'll come back to it to fix device related issues.
monojenkins added a commit to monojenkins/mono that referenced this issue Jun 6, 2019
…r LLVM

Contributes to mono#9621
Fixes mono#14841

Note that it breaks iOS 32bit on devices. The Apple Watch _might_ still works (only tested on `2019-02`).  It unblocks some build related issues on the Xamarin.iOS `2019-06` integration, and we have to do it anyway. I'll come back to it to fix device related issues.
akoeplinger added a commit that referenced this issue Jun 6, 2019
…r LLVM (#14856)

Contributes to #9621
Fixes #14841

Note that it breaks iOS 32bit on devices. The Apple Watch _might_ still works (only tested on `2019-02`).  It unblocks some build related issues on the Xamarin.iOS `2019-06` integration, and we have to do it anyway. I'll come back to it to fix device related issues.
akoeplinger added a commit that referenced this issue Jun 6, 2019
…r LLVM (#14852)

Contributes to #9621
Fixes #14841

Note that it breaks iOS 32bit on devices. The Apple Watch _might_ still works (only tested on `2019-02`).  It unblocks some build related issues on the Xamarin.iOS `2019-06` integration, and we have to do it anyway. I'll come back to it to fix device related issues.
akoeplinger added a commit to xamarin/xamarin-macios that referenced this issue Jun 6, 2019
lewurm added a commit to lewurm/mono that referenced this issue Jun 17, 2019
monojenkins added a commit to monojenkins/mono that referenced this issue Jul 5, 2019
Untested, but we need to do it anyway soon. This will help us to understand the situation on Xamarin.Android while finishing the work for Xamarin.iOS.

Contributes to mono#9621
akoeplinger added a commit that referenced this issue Jul 5, 2019
Untested, but we need to do it anyway soon. This will help us to understand the situation on Xamarin.Android while finishing the work for Xamarin.iOS.

Contributes to #9621

Backport of #15553.
lewurm added a commit to lewurm/mono that referenced this issue Jul 8, 2019
Instead of
```
push    {r4, r5, r6, r7, r10, r11, lr}
```

LLVM will generate
```
push    {r4, r5, r6, r7, lr}
add r7, sp, mono#4
push    {r9, r10}
```

Seems like this mono/llvm@a04e9e4 assumes that `-disable-fp-elim` is passed for iOS targets. I wondered why this wouldn't break things for them, but when you run `clang` from Xcode with `-v`, you will discover that its driver passes `-mdisable-fp-elim`.

Together with mono/llvm#48 this fixes crashes with FullAOT+LLVM on iOS 32bit.

Fixes mono#15058

Contributes to mono#9621
lewurm added a commit to lewurm/mono that referenced this issue Jul 8, 2019
Instead of
```
push    {r4, r5, r6, r7, r10, r11, lr}
```

LLVM will generate
```
push    {r4, r5, r6, r7, lr}
add     r7, sp, mono#12
push    {r10, r11}
```

Seems like this mono/llvm@a04e9e4 assumes that `-disable-fp-elim` is passed for iOS targets. I wondered why this wouldn't break things for them, but when you run `clang` from Xcode with `-v`, you will discover that its driver passes `-mdisable-fp-elim`.

Together with mono/llvm#48 this fixes crashes with FullAOT+LLVM on iOS 32bit.

Fixes mono#15058

Contributes to mono#9621
monojenkins added a commit to monojenkins/mono that referenced this issue Jul 8, 2019
Instead of
```
push    {r4, r5, r6, r7, r10, r11, lr}
```

LLVM will generate
```
push    {r4, r5, r6, r7, lr}
add     r7, sp, mono#12
push    {r10, r11}
```

Seems like this mono/llvm@a04e9e4 assumes that `-disable-fp-elim` is passed for iOS targets. I wondered why this wouldn't break things for them, but when you run `clang` from Xcode with `-v`, you will discover that its driver passes `-mdisable-fp-elim`.

Together with mono/llvm#48 this fixes crashes with FullAOT+LLVM on iOS 32bit.

Fixes mono#15058

Contributes to mono#9621
monojenkins added a commit that referenced this issue Jul 9, 2019
[2019-06] [llvm] avoid FP elimination on iOS/armv7

Instead of
```
push    {r4, r5, r6, r7, r10, r11, lr}
```

LLVM will generate
```
push    {r4, r5, r6, r7, lr}
add     r7, sp, #12
push    {r9, r10}
```

Seems like this mono/llvm@a04e9e4 assumes that `-disable-fp-elim` is passed for iOS targets. I wondered why this wouldn't break things for them, but when you run `clang` from Xcode with `-v`, you will discover that its driver passes `-mdisable-fp-elim`.

Together with mono/llvm#48 this fixes crashes with FullAOT+LLVM on iOS 32bit.

Fixes #15058

Contributes to #9621



Backport of #15617.

/cc @lewurm
monojenkins added a commit that referenced this issue Jul 14, 2019
[llvm] avoid FP elimination on iOS/armv7

Instead of
```
push    {r4, r5, r6, r7, r10, r11, lr}
```

LLVM will generate
```
push    {r4, r5, r6, r7, lr}
add     r7, sp, #12
push    {r9, r10}
```

Seems like this mono/llvm@a04e9e4 assumes that `-disable-fp-elim` is passed for iOS targets. I wondered why this wouldn't break things for them, but when you run `clang` from Xcode with `-v`, you will discover that its driver passes `-mdisable-fp-elim`.

Together with mono/llvm#48 this fixes crashes with FullAOT+LLVM on iOS 32bit.

Fixes #15058

Contributes to #9621
@marek-safar marek-safar moved this from Backlog to In progress in Short Term Projects Jul 15, 2019
mandel-macaque added a commit to xamarin/xamarin-macios that referenced this issue Jul 16, 2019
* Use the commonly used casing for `MSBuildSDKsPath` property

Handle "incorrectly" cased msbuild property names

msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.

* [mtouch] Whitelist new Brotli native symbols in Xamarin.Tests.Misc.PublicSymbols test

* [mtouch] Better assert in NoLLVMFailuresInWatchOS() test

We'd list the "LLVM failed" messages before even though the AOT might've crashed and the list is meaningless. Assert the exit code before that.

* [mtouch] Use new LLVM even for 32bit targets

See mono/mono#14841 and mono/mono#9621

* [mtouch] Work around slow LLVM in "don't link" test

See mono/mono#14843

* Remove useless conditional

* Remove LLVM36 from Makefile

* [watch4] set right min version for arm64_32 based watch devices (#6307)

Fixes the confusion around `libmono-native*` (see for example ce5ba1e#commitcomment-33834491 ) when building with `MONO_BUILD_FROM_SOURCE=1`.

* reflect watchos64_32_version_min change from mono sdk

* Move mono hash info to mk/mono.mk so that existing scripts work.

* Add Makefile dependency on mono.mk where necessary

With 3e7bc29 the Mono hash was moved from Make.config to mono.mk.

We need to add a Makefile dependency on this file wherever Make.config was used to track a Mono dependency.

* [tests] Copy mk/mono.mk to the XM test package.

* [tests] Update minOS version test after consolidating min watchOS versions everywhere.

Fixes this mtouch and mmptest failure:

    1) Failed : Xamarin.Tests.ProductTests.MinOSVersion(watchOS,MinwatchOS,WatchOSSimulator,False)
      Failures
      Expected: <empty>
      But was:  < "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (mono-runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-generated-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (shared-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-invoke-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (xamarin-support-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (nsstring-localization-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-varargs-debug.arm64_32.o)."... >

* [mmp] Fix make clean target

It needs an -r to remove directories:

```
rm: bin: is a directory
rm: obj: is a directory
```

* Add new xamarin_timezone_get_local_name() to a few more places
akoeplinger added a commit that referenced this issue Jul 19, 2019
The C# version doesn't work on 64bit. It would require to update its dependencies, but Zoltan already added a Python version for WebAssembly which works fine.

Some notes:
* changed the semantics of `--xcode-path` in order to match the output of `xcode-select -p`
* switched to python3/pip3
* removed hack for arm64_32, it works properly now because the Python version uses stock `clang`
* removed some leftover usages of `XCODE32_DIR`.

Manually verified by comparing output with the C# version.

This will unblock the iOS team when building on Catalina/Xcode11, as they can't consume SDK archives there. See xamarin/xamarin-macios#6603 (comment)

Contributes to #9621
lewurm added a commit to lewurm/mono that referenced this issue Jul 19, 2019
The C# version doesn't work on 64bit. It would require to update its dependencies, but Zoltan already added a Python version for WebAssembly which works fine.

Some notes:
* changed the semantics of `--xcode-path` in order to match the output of `xcode-select -p`
* switched to python3/pip3
* removed hack for arm64_32, it works properly now because the Python version uses stock `clang`
* removed some leftover usages of `XCODE32_DIR`.

Manually verified by comparing output with the C# version.

This will unblock the iOS team when building on Catalina/Xcode11, as they can't consume SDK archives there. See xamarin/xamarin-macios#6603 (comment)

Contributes to mono#9621
akoeplinger added a commit that referenced this issue Jul 19, 2019
The C# version doesn't work on 64bit. It would require to update its dependencies, but Zoltan already added a Python version for WebAssembly which works fine.

Some notes:
* changed the semantics of `--xcode-path` in order to match the output of `xcode-select -p`
* switched to python3/pip3
* removed hack for arm64_32, it works properly now because the Python version uses stock `clang`
* removed some leftover usages of `XCODE32_DIR`.

Manually verified by comparing output with the C# version.

This will unblock the iOS team when building on Catalina/Xcode11, as they can't consume SDK archives there. See xamarin/xamarin-macios#6603 (comment)

Contributes to #9621
 master (#15744)
lewurm added a commit to lewurm/mono that referenced this issue Jul 25, 2019
Short Term Projects automation moved this from In progress to Completed Tasks in this Sprint Jul 26, 2019
monojenkins added a commit that referenced this issue Jul 26, 2019
[android] switch to python offset tool

And drop C# tool.

Fixes #9621
@marek-safar marek-safar moved this from Completed Tasks in this Sprint to Done in Short Term Projects Aug 5, 2019
pjcollins added a commit to xamarin/xamarin-android that referenced this issue Aug 9, 2019
Context: mono/mono#9621
Context: http://build.azdo.io/2927809

We've been encountering a build error attempting to strip `cross-arm.exe`
in recent mono bump attempts. This is occurring because the Android mono
archive no longer contains 32bit cross compilers. The mono archive also
no longer contains any `llvmwin32` content.

Fix the build by using 64bit strip tools on Windows, and by removing the
reference to a Windows 32bit LLVM runtime which no longer exists.
pjcollins added a commit to jonpryor/xamarin-android that referenced this issue Aug 9, 2019
Context: mono/mono#9621
Context: http://build.azdo.io/2927809

We've been encountering a build error attempting to strip `cross-arm.exe`
in recent mono bump attempts. This is occurring because the Android mono
archive no longer contains 32bit cross compilers. The mono archive also
no longer contains any `llvmwin32` content.

Fix the build by using 64bit strip tools on Windows, and by removing the
reference to a Windows 32bit LLVM runtime which no longer exists.
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Aug 10, 2019
Context: mono/mono#9621
Context: http://build.azdo.io/2927809

Fixes: mono/mono#15261
Fixes: mono/mono#15262
Fixes: mono/mono#15263
Fixes: mono/mono#15307
Fixes: mono/mono#15751
Fixes: mono/mono#15825
Fixes: mono/mono#15878
Fixes: mono/mono#15887

[w32socket] Translate ELOOP and ENAMETOOLONG

[corlib] Ignore TimeZoneTest.TestCtors on Android GMT

Additionally, mono cross compilers are now always 64-bit, as are the
LLVM runtimes.  64-bit cross-compilers broke the xamarin-android
build, as it was using a 32-bit `strip` on them, which failed.

Use the correct `strip` utility, and remove the reference to a
Windows 32bit LLVM runtime which no longer exists.

The mono archive also no longer contains any `llvmwin32` content,
so ensure that the correct LLVM runtimes are installed.
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Aug 14, 2019
Changes: mono/mono@761220d...a791989

Fixes: mono/mono#15261
Fixes: mono/mono#15262
Fixes: mono/mono#15263
Fixes: mono/mono#15307
Fixes: mono/mono#15575
Fixes: mono/mono#15751
Fixes: mono/mono#15825
Fixes: mono/mono#15878
Fixes: mono/mono#15887
Fixes: mono/mono#16010

Context: mono/mono#9621
Context: http://build.azdo.io/2927809

Fix `Socket.ConnectAsync(SocketAsyncEventArgs)` behavior

Ignores `TimeZoneTest.TestCtors` on Android GMT, as
`TimeZone.CurrentTimeZone.DaylightName` is an empty value.

[w32socket] Translate ELOOP and ENAMETOOLONG

Additionally, mono cross compilers are now always 64-bit, as are the
LLVM runtimes.  64-bit cross-compilers broke the xamarin-android
build, as it was using a 32-bit `strip` on them, which failed.

Use the correct `strip` utility, and remove the reference to a
Windows 32bit LLVM runtime which no longer exists.

The mono archive also no longer contains any `llvmwin32` content,
so ensure that the correct LLVM runtimes are installed.
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Sep 6, 2019
Changes: http://github.com/mono/mono/compare/2c3aeaf3780de7392a0d3cbe4dcf86846eb4dffa...29b1ac19c961b959a09097dbc0fe4cd567cc5298

	$ git diff --shortstat 2c3aeaf3..29b1ac19
	 1528 files changed, 45421 insertions(+), 21967 deletions(-)

Changes: mono/api-doc-tools@d03e819...5da8127

	$ git diff --shortstat d03e8198..5da8127a
	 1001 files changed, 86168 insertions(+), 11863 deletions(-)

Changes: mono/api-snapshot@e09042d...1ca8e82

	$ git diff --shortstat e09042da..1ca8e82f
        28 files changed, 612 insertions(+), 217 deletions(-)

Changes: mono/cecil@a6c8f5e...cb6c1ca

	$ git diff --shortstat a6c8f5e1..cb6c1ca9
	 13 files changed, 233 insertions(+), 88 deletions(-)

Changes: mono/corefx@4806207...470e0e1

	$ git diff --shortstat 4806207f...470e0e10
	 4 files changed, 31 insertions(+), 12 deletions(-)

Changes: mono/linker@ebe2a1f...1f87de3

	$ git diff --shortstat ebe2a1f4...1f87de35
        90 files changed, 3219 insertions(+), 1224 deletions(-)

Changes: xamarin/java.interop@befdbc0...be6048e

	$ git diff --shortstat befdbc03...be6048ed
        3 files changed, 3 insertions(+), 3 deletions(-)

Upstream-Fixes: https://bugs.winehq.org/show_bug.cgi?id=47561
Upstream-Fixes: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582
Upstream-Fixes: dotnet/coreclr#25071
Upstream-Fixes: dotnet/coreclr#25242
Upstream-Fixes: dotnet/coreclr#25632
Upstream-Fixes: dotnet/coreclr#25709
Upstream-Fixes: dotnet/corefx#37955
Upstream-Fixes: dotnet/corefx#38455
Upstream-Fixes: mono/mono#7377
Upstream-Fixes: mono/mono#8747
Upstream-Fixes: mono/mono#9621
Upstream-Fixes: mono/mono#9664
Upstream-Fixes: mono/mono#9706
Upstream-Fixes: mono/mono#10201
Upstream-Fixes: mono/mono#10645
Upstream-Fixes: mono/mono#10748
Upstream-Fixes: mono/mono#10848
Upstream-Fixes: mono/mono#12141
Upstream-Fixes: mono/mono#13311
Upstream-Fixes: mono/mono#13408
Upstream-Fixes: mono/mono#13412
Upstream-Fixes: mono/mono#13891
Upstream-Fixes: mono/mono#13923
Upstream-Fixes: mono/mono#13945
Upstream-Fixes: mono/mono#14170
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14215
Upstream-Fixes: mono/mono#14243
Upstream-Fixes: mono/mono#14377
Upstream-Fixes: mono/mono#14495
Upstream-Fixes: mono/mono#14555
Upstream-Fixes: mono/mono#14724
Upstream-Fixes: mono/mono#14729
Upstream-Fixes: mono/mono#14772
Upstream-Fixes: mono/mono#14792
Upstream-Fixes: mono/mono#14793
Upstream-Fixes: mono/mono#14809
Upstream-Fixes: mono/mono#14830
Upstream-Fixes: mono/mono#14839
Upstream-Fixes: mono/mono#14841
Upstream-Fixes: mono/mono#14847
Upstream-Fixes: mono/mono#14864
Upstream-Fixes: mono/mono#14871
Upstream-Fixes: mono/mono#14917
Upstream-Fixes: mono/mono#14945
Upstream-Fixes: mono/mono#14946
Upstream-Fixes: mono/mono#14948
Upstream-Fixes: mono/mono#14957
Upstream-Fixes: mono/mono#14959
Upstream-Fixes: mono/mono#14960
Upstream-Fixes: mono/mono#14961
Upstream-Fixes: mono/mono#14963
Upstream-Fixes: mono/mono#14971
Upstream-Fixes: mono/mono#14972
Upstream-Fixes: mono/mono#14975
Upstream-Fixes: mono/mono#15023
Upstream-Fixes: mono/mono#15048
Upstream-Fixes: mono/mono#15058
Upstream-Fixes: mono/mono#15080
Upstream-Fixes: mono/mono#15182
Upstream-Fixes: mono/mono#15188
Upstream-Fixes: mono/mono#15189
Upstream-Fixes: mono/mono#15261
Upstream-Fixes: mono/mono#15262
Upstream-Fixes: mono/mono#15263
Upstream-Fixes: mono/mono#15265
Upstream-Fixes: mono/mono#15268
Upstream-Fixes: mono/mono#15307
Upstream-Fixes: mono/mono#15324
Upstream-Fixes: mono/mono#15329
Upstream-Fixes: mono/mono#15330
Upstream-Fixes: mono/mono#15441
Upstream-Fixes: mono/mono#15446
Upstream-Fixes: mono/mono#15503
Upstream-Fixes: mono/mono#15541
Upstream-Fixes: mono/mono#15551
Upstream-Fixes: mono/mono#15556
Upstream-Fixes: mono/mono#15596
Upstream-Fixes: mono/mono#15691
Upstream-Fixes: mono/mono#15692
Upstream-Fixes: mono/mono#15740
Upstream-Fixes: mono/mono#15751
Upstream-Fixes: mono/mono#15760
Upstream-Fixes: mono/mono#15781
Upstream-Fixes: mono/mono#15794
Upstream-Fixes: mono/mono#15825
Upstream-Fixes: mono/mono#15853
Upstream-Fixes: mono/mono#15878
Upstream-Fixes: mono/mono#15887
Upstream-Fixes: mono/mono#15990
Upstream-Fixes: mono/mono#16032
Upstream-Fixes: mono/mono#16411
Upstream-Fixes: mono/mono#16486
Upstream-Fixes: https://github.com/mono/mono/issues/25709
Upstream-Fixes: https://github.com/mono/mono/issues/38821
Upstream-Fixes: #3112
Upstream-Fixes: #3168

Update `build-tools/automation/build.groovy` so that it fully cleans
the build tree before starting the build, so that the vestigial mono
submodule (removed in 0c9f83b) is *actually* removed from the build
tree, so that we don't inadvertently use *ancient* submodule contents.
jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Sep 6, 2019
Changes: http://github.com/mono/mono/compare/2c3aeaf3780de7392a0d3cbe4dcf86846eb4dffa...29b1ac19c961b959a09097dbc0fe4cd567cc5298

	$ git diff --shortstat 2c3aeaf3..29b1ac19
	 1528 files changed, 45421 insertions(+), 21967 deletions(-)

Changes: mono/api-doc-tools@d03e819...5da8127

	$ git diff --shortstat d03e8198..5da8127a
	 1001 files changed, 86168 insertions(+), 11863 deletions(-)

Changes: mono/api-snapshot@e09042d...1ca8e82

	$ git diff --shortstat e09042da..1ca8e82f
        28 files changed, 612 insertions(+), 217 deletions(-)

Changes: mono/cecil@a6c8f5e...cb6c1ca

	$ git diff --shortstat a6c8f5e1..cb6c1ca9
	 13 files changed, 233 insertions(+), 88 deletions(-)

Changes: mono/corefx@4806207...470e0e1

	$ git diff --shortstat 4806207f...470e0e10
	 4 files changed, 31 insertions(+), 12 deletions(-)

Changes: mono/linker@ebe2a1f...1f87de3

	$ git diff --shortstat ebe2a1f4...1f87de35
	 90 files changed, 3219 insertions(+), 1224 deletions(-)

Changes: xamarin/java.interop@75b1189...4fd3539

	$ git diff --shortstat 75b11891...4fd35393
	 34 files changed, 448 insertions(+), 52 deletions(-)

Upstream-Fixes: https://bugs.winehq.org/show_bug.cgi?id=47561
Upstream-Fixes: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582
Upstream-Fixes: dotnet/coreclr#25071
Upstream-Fixes: dotnet/coreclr#25242
Upstream-Fixes: dotnet/coreclr#25632
Upstream-Fixes: dotnet/coreclr#25709
Upstream-Fixes: dotnet/corefx#37955
Upstream-Fixes: dotnet/corefx#38455
Upstream-Fixes: mono/mono#7377
Upstream-Fixes: mono/mono#8747
Upstream-Fixes: mono/mono#9621
Upstream-Fixes: mono/mono#9664
Upstream-Fixes: mono/mono#9706
Upstream-Fixes: mono/mono#10201
Upstream-Fixes: mono/mono#10645
Upstream-Fixes: mono/mono#10748
Upstream-Fixes: mono/mono#10848
Upstream-Fixes: mono/mono#12141
Upstream-Fixes: mono/mono#13311
Upstream-Fixes: mono/mono#13408
Upstream-Fixes: mono/mono#13412
Upstream-Fixes: mono/mono#13891
Upstream-Fixes: mono/mono#13923
Upstream-Fixes: mono/mono#13945
Upstream-Fixes: mono/mono#14170
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14214
Upstream-Fixes: mono/mono#14215
Upstream-Fixes: mono/mono#14243
Upstream-Fixes: mono/mono#14377
Upstream-Fixes: mono/mono#14495
Upstream-Fixes: mono/mono#14555
Upstream-Fixes: mono/mono#14724
Upstream-Fixes: mono/mono#14729
Upstream-Fixes: mono/mono#14772
Upstream-Fixes: mono/mono#14792
Upstream-Fixes: mono/mono#14793
Upstream-Fixes: mono/mono#14809
Upstream-Fixes: mono/mono#14830
Upstream-Fixes: mono/mono#14839
Upstream-Fixes: mono/mono#14841
Upstream-Fixes: mono/mono#14847
Upstream-Fixes: mono/mono#14864
Upstream-Fixes: mono/mono#14871
Upstream-Fixes: mono/mono#14917
Upstream-Fixes: mono/mono#14945
Upstream-Fixes: mono/mono#14946
Upstream-Fixes: mono/mono#14948
Upstream-Fixes: mono/mono#14957
Upstream-Fixes: mono/mono#14959
Upstream-Fixes: mono/mono#14960
Upstream-Fixes: mono/mono#14961
Upstream-Fixes: mono/mono#14963
Upstream-Fixes: mono/mono#14971
Upstream-Fixes: mono/mono#14972
Upstream-Fixes: mono/mono#14975
Upstream-Fixes: mono/mono#15023
Upstream-Fixes: mono/mono#15048
Upstream-Fixes: mono/mono#15058
Upstream-Fixes: mono/mono#15080
Upstream-Fixes: mono/mono#15182
Upstream-Fixes: mono/mono#15188
Upstream-Fixes: mono/mono#15189
Upstream-Fixes: mono/mono#15261
Upstream-Fixes: mono/mono#15262
Upstream-Fixes: mono/mono#15263
Upstream-Fixes: mono/mono#15265
Upstream-Fixes: mono/mono#15268
Upstream-Fixes: mono/mono#15307
Upstream-Fixes: mono/mono#15324
Upstream-Fixes: mono/mono#15329
Upstream-Fixes: mono/mono#15330
Upstream-Fixes: mono/mono#15441
Upstream-Fixes: mono/mono#15446
Upstream-Fixes: mono/mono#15503
Upstream-Fixes: mono/mono#15541
Upstream-Fixes: mono/mono#15551
Upstream-Fixes: mono/mono#15556
Upstream-Fixes: mono/mono#15596
Upstream-Fixes: mono/mono#15691
Upstream-Fixes: mono/mono#15692
Upstream-Fixes: mono/mono#15740
Upstream-Fixes: mono/mono#15751
Upstream-Fixes: mono/mono#15760
Upstream-Fixes: mono/mono#15781
Upstream-Fixes: mono/mono#15794
Upstream-Fixes: mono/mono#15825
Upstream-Fixes: mono/mono#15853
Upstream-Fixes: mono/mono#15878
Upstream-Fixes: mono/mono#15887
Upstream-Fixes: mono/mono#15990
Upstream-Fixes: mono/mono#16032
Upstream-Fixes: mono/mono#16411
Upstream-Fixes: mono/mono#16486
Upstream-Fixes: https://github.com/mono/mono/issues/25709
Upstream-Fixes: https://github.com/mono/mono/issues/38821
Upstream-Fixes: xamarin#3112
Upstream-Fixes: xamarin#3168

Update `build-tools/automation/build.groovy` so that it fully cleans
the build tree before starting the build, so that the vestigial mono
submodule (removed in 0c9f83b) is *actually* removed from the build
tree, so that we don't inadvertently use *ancient* submodule contents.
jonpryor added a commit to xamarin/xamarin-android that referenced this issue Sep 7, 2019
Changes: http://github.com/mono/mono/compare/2c3aeaf3780de7392a0d3cbe4dcf86846eb4dffa...29b1ac19c961b959a09097dbc0fe4cd567cc5298

	$ git diff --shortstat 2c3aeaf3..29b1ac19
	 1528 files changed, 45421 insertions(+), 21967 deletions(-)

Changes: mono/api-doc-tools@d03e819...5da8127

	$ git diff --shortstat d03e8198..5da8127a
	 1001 files changed, 86168 insertions(+), 11863 deletions(-)

Changes: mono/api-snapshot@e09042d...1ca8e82

	$ git diff --shortstat e09042da..1ca8e82f
        28 files changed, 612 insertions(+), 217 deletions(-)

Changes: mono/cecil@a6c8f5e...cb6c1ca

	$ git diff --shortstat a6c8f5e1..cb6c1ca9
	 13 files changed, 233 insertions(+), 88 deletions(-)

Changes: mono/corefx@4806207...470e0e1

	$ git diff --shortstat 4806207f...470e0e10
	 4 files changed, 31 insertions(+), 12 deletions(-)

Changes: mono/linker@ebe2a1f...1f87de3

	$ git diff --shortstat ebe2a1f4...1f87de35
	 90 files changed, 3219 insertions(+), 1224 deletions(-)

Changes: xamarin/java.interop@75b1189...4fd3539

	$ git diff --shortstat 75b11891...4fd35393
	 34 files changed, 448 insertions(+), 52 deletions(-)

Fixes: #3112
Fixes: #3168

Context: https://bugs.winehq.org/show_bug.cgi?id=47561
Context: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/967582
Context: dotnet/coreclr#25071
Context: dotnet/coreclr#25242
Context: dotnet/coreclr#25632
Context: dotnet/coreclr#25709
Context: dotnet/corefx#37955
Context: dotnet/corefx#38455
Context: mono/mono#7377
Context: mono/mono#8747
Context: mono/mono#9621
Context: mono/mono#9664
Context: mono/mono#9706
Context: mono/mono#10201
Context: mono/mono#10645
Context: mono/mono#10748
Context: mono/mono#10848
Context: mono/mono#12141
Context: mono/mono#13311
Context: mono/mono#13408
Context: mono/mono#13412
Context: mono/mono#13891
Context: mono/mono#13923
Context: mono/mono#13945
Context: mono/mono#14170
Context: mono/mono#14214
Context: mono/mono#14214
Context: mono/mono#14215
Context: mono/mono#14243
Context: mono/mono#14377
Context: mono/mono#14495
Context: mono/mono#14555
Context: mono/mono#14724
Context: mono/mono#14729
Context: mono/mono#14772
Context: mono/mono#14792
Context: mono/mono#14793
Context: mono/mono#14809
Context: mono/mono#14830
Context: mono/mono#14839
Context: mono/mono#14841
Context: mono/mono#14847
Context: mono/mono#14864
Context: mono/mono#14871
Context: mono/mono#14917
Context: mono/mono#14945
Context: mono/mono#14946
Context: mono/mono#14948
Context: mono/mono#14957
Context: mono/mono#14959
Context: mono/mono#14960
Context: mono/mono#14961
Context: mono/mono#14963
Context: mono/mono#14971
Context: mono/mono#14972
Context: mono/mono#14975
Context: mono/mono#15023
Context: mono/mono#15048
Context: mono/mono#15058
Context: mono/mono#15080
Context: mono/mono#15182
Context: mono/mono#15188
Context: mono/mono#15189
Context: mono/mono#15261
Context: mono/mono#15262
Context: mono/mono#15263
Context: mono/mono#15265
Context: mono/mono#15268
Context: mono/mono#15307
Context: mono/mono#15324
Context: mono/mono#15329
Context: mono/mono#15330
Context: mono/mono#15441
Context: mono/mono#15446
Context: mono/mono#15503
Context: mono/mono#15541
Context: mono/mono#15551
Context: mono/mono#15556
Context: mono/mono#15596
Context: mono/mono#15691
Context: mono/mono#15692
Context: mono/mono#15740
Context: mono/mono#15751
Context: mono/mono#15760
Context: mono/mono#15781
Context: mono/mono#15794
Context: mono/mono#15825
Context: mono/mono#15853
Context: mono/mono#15878
Context: mono/mono#15887
Context: mono/mono#15990
Context: mono/mono#16032
Context: mono/mono#16411
Context: mono/mono#16486
Context: https://github.com/mono/mono/issues/25709
Context: https://github.com/mono/mono/issues/38821

Update `build-tools/automation/build.groovy` so that it fully cleans
the build tree before starting the build, so that the vestigial mono
submodule (removed in 0c9f83b) is *actually* removed from the build
tree, so that we don't inadvertently use *ancient* submodule contents.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
3 participants
You can’t perform that action at this time.