cc @am11 @DamianEdwards @akoeplinger

Can you show the error and which runtime commit you were trying with (latest main in runtime should have all the changes which we have here)? This is exactly what we had before, so I'm not sure how is it broken.

Related PR: dotnet/dotnet#6802

That PR moved the code to a shared location without changing the logic except for include semantics. It's unclear what has it broken that we are fixing here.

Can you show the error and which runtime commit you were trying with (latest main in runtime should have all the changes which we have here)? This is exactly what we had before, so I'm not sure how is it broken.

Sorry for confusion, this is not a newly introduced issue. dotnet/dotnet#6802 is related only in sense that it moves similar logic to eng/common/native/LocateNativeCompiler.targets, and changes should get here and not in runtime repo. Actually, this issue is present in release/10.0 branch of runtime too.

Error below happens during tizen cross build, because tizen rootfs requires additional linker flags, which are specified in toolchain.cmake.

 Generating native code
ld.lld : error : /home/runtime/.tools/rootfs/x64/usr/lib/../lib64/libc.so:5: unable to find libc.so.6 [/home/runtime/src/coreclr/tools/aot/ILCompiler/ILCompiler_publish.csproj]
 >>> GROUP ( libc.so.6 libc_nonshared.a AS_NEEDED ( ld-linux-x86-64.so.2 ) )
 >>> ^

Thanks for the clarification.

because tizen rootfs requires additional linker flags

The linker flags in LocateNativeCompiler is basically just to capture a high-level "which compiler and which linker to use" (name/path and version). The actual linker flags per-platform are coded in runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets. All other platform's cross-build rootfs are mimicking the actual OS structure, so whether we are publishing an AOT app locally on the platform or cross-publishing via this rootfs (or any other "standard-looking" cross-build toolchain), it works. Is tizen rootfs following the structure of original operating system? If so, we can just encode them in Microsoft.NETCore.Native.Unix.targets like we have for FreeBSD, OpenBSD etc.

Is tizen rootfs following the structure of original operating system?

Yes

If so, we can just encode them in Microsoft.NETCore.Native.Unix.targets like we have for FreeBSD, OpenBSD etc.

There would be some duplication in toolchain.cmake and src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets. Maybe GetCrossToolchainInfoAot can be called in case of native build too (currently it has cross build check), then FreeBSD, OpenBSD etc. won't need explicit -L flags in src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets.

Another problem I see with this is that _targetOS is just linux in src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets, not tizen.

We already have duplication in BuildIntegration, because we ship it in nuget package for PublishAot, that's why we were very careful about depending on anything outside the directory (except for LocateNativeCompiler for .NET CI/CD minimal overrides).

_targetOS is just linux in src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets, not tizen.

We can sub-classify Tizen like this https://github.com/dotnet/runtime/blob/5e3dadb4a2b39e6e32127ecd0038854a338773e7/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets#L63.

Thanks for explanation, I'll update based on your suggestions

Closing this in favor of dotnet/runtime#129844