Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

cc @jkotas, reverted pinned container reference. FreeBSD legs are green. It was this change in cmake 3.25 which sets LINUX to 1: Kitware/CMake@62cd390.

We have similar code in eng/native/tryrun.cmake. This sounds like a cmake bug to me, could you please report it to them?

The changelog only mentions this so I don't think it should be set on freebsd:

The LINUX and CMAKE_HOST_LINUX variables are now set to true when the target or host system is Linux, respectively.

Maybe we should also stop relying on these variables and introduce our own (e.g. similar to the CLR_CMAKE_HOST_FREEBSD)

Ah this is in the cross-build docker images so the host system is actually Linux right? That makes more sense then and makes me wish we'd stop using these variables even more.

It can refactored separately, I don't feel strongly that we should; because:

1. The toolchain file and try_compile is a cmake built-in mechanism and cmake invokes these files at different times with different contexts in cross-build mode. We should not mix the variable names which will be set later by configureplatform.cmake (e.g. CLR_CMAKE_HOST_FREEBSD).

2. The root-cause of why Linux.cmake is even included in the toolchain file (which is supposed to act like a seed file in cross-compilation mode to locate usable toolchain) is because we make decision about the target platform in this file, rather than before invoking cmake. We can easily move these conditions:

   runtime/eng/common/cross/toolchain.cmake

   Lines 10 to 23 in 9ff3fc2

   	set(TARGET_ARCH_NAME $ENV{TARGET_BUILD_ARCH})
   	if(EXISTS ${CROSS_ROOTFS}/bin/freebsd-version)
   	set(CMAKE_SYSTEM_NAME FreeBSD)
   	set(FREEBSD 1)
   	elseif(EXISTS ${CROSS_ROOTFS}/usr/platform/i86pc)
   	set(CMAKE_SYSTEM_NAME SunOS)
   	set(ILLUMOS 1)
   	elseif(EXISTS ${CROSS_ROOTFS}/boot/system/develop/headers/config/HaikuConfig.h)
   	set(CMAKE_SYSTEM_NAME Haiku)
   	else()
   	set(CMAKE_SYSTEM_NAME Linux)
   	set(LINUX 1)
   	endif()
   	set(CMAKE_SYSTEM_VERSION 1)

   to gen-buildsys.sh and set CMAKE_SYSTEM_NAME to the desired target platform before invoking cmake (as we already do for Darwin in gen-buildsys.sh..). But we haven't done that intentionally from the get go because we wanted to keep build-rootfs.sh and toolchain.cmake pair tightly coupled and independent; those hint paths to detect platform come from (or cause by) build-rootfs.sh.

Yeah I'm mostly worried that we're basically overriding CMake-internal variables and who knows what impact that has.

It is a predefined variable. We overwrite predefined variables all over the place. All CMAKE_* are predefined variables, for example. I don't think there is anything to worry about here.

I agree with @am11 that overwriting built-in CMake variables during cross-compilation seems to be pretty standard pattern. It is even suggested in official CMake docs.

All failures are known issues according to the Build Analysis.

Right but we're apparently using these variables not in the way that cmake intended (i.e. for cross compilation targets rather than the host OS). I think refactoring to use e.g. a CROSS_TARGET_ prefix would make it clearer.

We also need to backport this or some other fix to all servicing branches.

we're apparently using these variables not in the way that cmake intended (i.e. for cross compilation targets rather than the host OS).

CMake documentation says that it is meant to represent target system: Kitware/CMake@62cd390#diff-186bb1bd28bd5ab49edaeb9820e3a5218c73bf02fec15bd71d221da5a130608bR4

Ah ok, yeah then this approach looks good to me.

We also need to backport this or some other fix to all servicing branches.

I have triggered the backports in arcade repo. We can let the codeflow to take care of the rest in the servicing trees.