Yes. The problem is that the runtime's build scripts process and change the passed in TargetOS when determining the RID. Because of our "nested inner build" logic, we effectively were stripping the "-bionic" part of "linux-bionic" from the inner build invocation and building the product in a weird blend of linux, linux-bionic, and android.

By letting this calculation happen again and overwriting the TargetOS based on the RID, we can restore the calculation of the TargetOS to the correct value by re-extracting it from the RID (which we calculate based on the originally-passed-in TargetOS).

My 2 cents: it may be interesting to globally introduce a property that is the "portable rid OS corresponding to the target". That one would be linux-bionic. dotnet/sdk#44800 is also about having such a property.

Because of our "nested inner build" logic, we effectively were stripping the "-bionic" part of "linux-bionic" from the inner build invocation and building the product in a weird blend of linux, linux-bionic, and android.

It sounds like we are missing handling of linux-bionic somewhere next to the existing handling of linux-musl which should have the same behavior but doesn't (e.g. alpine distro packages use source-build without issues). If we can find and fix that problem, I think that would be better targeted fix rather than exposing these props.

Ideally, eng/OSArch.props + eng/RuntimeIdentifier.props type of platform spec resolution should be shared via arcade/eng/common so the handling of supported platforms and effective platforms (build/host/target) is unified across the board; single source of truth.

Alpine doesn't have a problem because musl and glibc builds are more similar.

Coming back to this, here's the flow of what's happening in main and why musl doesn't have a problem here:

1. When the VMR orchestrator passes -os linux-bionic to the runtime outer build script, we hit this block:

   runtime/eng/build.sh

   Lines 290 to 292 in 7efe7f7

   	linux-bionic)
   	os="linux"
   	__PortableTargetOS=linux-bionic

2. We pass the os variable as the TargetOS property to the build:

   runtime/eng/build.sh

   Line 306 in 7efe7f7

   arguments="$arguments /p:TargetOS=$os"

3. We initialize the RID based on the os variable:

   runtime/eng/build.sh

   Line 558 in 7efe7f7

   runtime/eng/build.sh

   Lines 133 to 147 in 7efe7f7

   	initDistroRid()
   	{
   	source "$scriptroot"/common/native/init-distro-rid.sh
   	local passedRootfsDir=""
   	local targetOs="$1"
   	local targetArch="$2"
   	local isCrossBuild="$3"
   	# Only pass ROOTFS_DIR if __DoCrossArchBuild is specified and the current platform is not an Apple platform (that doesn't use rootfs)
   	if [[ $isCrossBuild == 1 && "$targetOs" != "osx" && "$targetOs" != "android" && "$targetOs" != "ios" && "$targetOs" != "iossimulator" && "$targetOs" != "tvos" && "$targetOs" != "tvossimulator" && "$targetOs" != "maccatalyst" ]]; then
   	passedRootfsDir=${ROOTFS_DIR}
   	fi
   	initDistroRidGlobal "${targetOs}" "${targetArch}" "${passedRootfsDir}"
   	}

4. The outer build tries to evaluate the TargetOS property based on the RID, but this is ignored:

   runtime/eng/DotNetBuild.props

   Line 18 in 7efe7f7

   <TargetOS>$(TargetRid.Substring(0, $(_targetRidPlatformIndex)))</TargetOS>

5. We pass the TargetOS property to the inner build:

   runtime/eng/DotNetBuild.props

   Line 67 in 7efe7f7

   <InnerBuildArgs Condition="'$(DotNetBuildSourceOnly)' != 'true'">$(InnerBuildArgs) $(FlagParameterPrefix)os $(TargetOS)</InnerBuildArgs>

6. The inner build sees the TargetOS property as linux instead of linux-bionic:

   runtime/eng/build.sh

   Lines 264 to 265 in 7efe7f7

   	linux)
   	os="linux" ;;

7. As linux-bionic is not a cross build, but linux is, we end up not having the -cross flag and build fails.

• linux-musl is a cross-build like linux, so -cross will be present. Since we have the correct RID passed in, we end up building everything correctly even though we pass -os linux today.
• If we pass the -cross flag for linux-bionic. We must pass a rootfs. If we pass a rootfs, we end up building the Android crypto stack instead of the OpenSSL one because we miss setting the "Force use OpenSSL Crypto" due to the rootfs being provided.

This change lets the logic at step 4 correct the adjustment in step 2 using the RID that's passed in by the orchestrator.

I'd like to get in this change as-is. After we switch to flat code-flow to the VMR, we can revisit how we handle RIDs and platform specification and simplify it from the VMR where we can do all the changes in one PR.

Note that in the first step, build.sh sets __PortableTargetOS=linux-bionic. dotnet/runtime then uses that to initialize _portableOS_. __PortableTargetOS/_portableOS_ gets lost when it goes from the vmr outer build to the runtime inner build (TargetOS=linux). For linux-musl the __PortableTargetOS gets "recovered" here.

Thanks for the explainer @jkoritzinsky and @tmds.

We were discussing whether it makes sense to maintain a standalone linux-bionic RID going forward: #106748 (comment). Probably telemetry would be able to clarify how many non-Android installations are using linux-bionic in .NET 8 and 9, and whether it would make sense to provide it with feature switches on top of android runtime. Separate RID implies that the maintainers of 3p nupkg with native assets need to provide two same/similar/identical binaries with different names per arch, both require Android NDK to be present on the build machine regardless the code uses any auxiliary platform feature. If the use-cases of linux-bionic are only dev oriented (such as Termux, which is an emulator), then we can likely live with a single android runtime. e.g. Rosetta emulator is also supported by osx-* RIDs without a specialized package for it. Runtime just disables doublemapping (DOTNET_EnableWriteXorExecute=0) among other features when emulator is detected. Windows, OSX and FreeBSD C libs are also tied to the platform (as bionic-libc is tied to Android) with no specialized runtime packs.

__PortableTargetOS/_portableOS_ gets lost when it goes from the vmr outer build to the runtime inner build (TargetOS=linux).

Probably it would be a better fix here if PortableTargetOS is propagated separately from VMR to inner builds. That sort of a subclass platform context maybe useful in other places.

Probably it would be a better fix here if PortableTargetOS is propagated separately from VMR to inner builds. That sort of a subclass platform context maybe useful in other places.

Yes, that was my suggestion in #113765 (comment).

I don't want to propagate it separately as our inner build invocation should be as close to a standard build invocation as possible. I don't want to have to maintain two different ways of passing the OS.

I'll see if I can make this a little cleaner.

I've pulled apart the RID calculations again and significantly cleaned them up and reduced the set of different RID concepts. Lets see how CI likes it.

/azp run runtime, runtime-diagnostics, runtime-dev-innerloop, dotnet-linker-tests

I've verified these changes with a full source-build (Fedora x64). I did not notice any differences between artifacts produced in the test build and the baseline. My test might not have exercised the code paths fully. @jkoritzinsky let me know if there is a more appropriate source-build scenario.

@jkoritzinsky assuming that this PR will remove the remaining runtime patch in the VMR, we need to get this in before April 23rd so that we are patch free by that date. Just in case you didn't know about this deadline.

Yeah I split off #114285 because of the deadline. I just need a code review and this will be ready to merge.