Work around for Android builds using GCC for cross compiler native tools build

[directhex]

Closes: #88344

[directhex]

Sigh. OK, so disabling the cross compiler is enough for the basic tests, but not the allsubsets tests (which have a hard dependency on a cross-compiler).

[directhex]

Blocking on dotnet/dotnet-buildtools-prereqs-docker#901

[directhex]

Reopening to test some more fixes. This will definitely NOT fix the Android AllSubsets builds, but might fix others

[directhex]

I'm confused why all these iOS/tvOS failures aren't expected. src/tests/tracing/eventpipe/processinfo3/processinfo3.cs specifies

            string expectedPortableRidOs = null;
            if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
            {
                expectedPortableRidOs = "win";
            }
            else if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX))
            {
                expectedPortableRidOs = "osx";
            }
            else if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
            {
                expectedPortableRidOs = "linux";
            }

            Utils.Assert(!string.IsNullOrEmpty(expectedPortableRidOs), $"Unable to calculate expected portable RID OS.");

Why would that ever pass on a platform that isn't OSX, Linux or Win? Hence [20:44:10] dbug: System.Exception: Unable to calculate expected portable RID OS.

[jkotas]

Why would that ever pass on a platform that isn't OSX, Linux or Win?

#88186

[directhex]

OK so most of the failures aren't my fault. Some, not all. Looks like the LLVM bump has cleared 3 failing lanes. I'll need to loop in @vargaz for the segfaults. The android failures are blocked on new docker images, which are failing to build due to disk space exhaustion

[ghost]

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Closes: #88344

Author:	directhex
Assignees:	directhex
Labels:	area-Infrastructure-mono
Milestone:	-

[directhex]

/azp run runtime-extra-platforms

[directhex]

/azp run runtime-wasm

[azure-pipelines]

No commit pushedDate could be found for PR 88345 in repo dotnet/runtime

[azure-pipelines]

No commit pushedDate could be found for PR 88345 in repo dotnet/runtime

[steveisok]

/azp run runtime-wasm

[azure-pipelines]

No commit pushedDate could be found for PR 88345 in repo dotnet/runtime

[directhex]

/azp run runtime-wasm

[directhex]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[azure-pipelines]

No commit pushedDate could be found for PR 88345 in repo dotnet/runtime

[directhex]

/azp run runtime-extra-platforms

[azure-pipelines]

No commit pushedDate could be found for PR 88345 in repo dotnet/runtime

[directhex]

OK, one /azp run worked and one didn't? This is not a productive way to do my job.

[directhex]

/azp run runtime-android

[azure-pipelines]

No commit pushedDate could be found for PR 88345 in repo dotnet/runtime

[directhex]

/azp run runtime-androidemulator

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[directhex]

Well we're gonna have to trust the androidemulator run, because none of the others feel like joining the party

[directhex]

This seems mergeable. We've gone from "Android jobs don't build" to "Android jobs build but there are some test failures" which feels like a big upgrade