[NativeAOT] Optionally compile unmanaged runtime at application build time

[jkotas]

Native AOT compiler package includes precompiled libraries (.lib/.a files) with unmanaged runtime code. This works well in most cases. However, we have seen situations where the precompiled libraries are not usable:

• LTCG optimization for unmanaged runtime code. LTCG optimizations require exact match between C++ compiler and native linker versions, that prevents us from enabling this optimization for native AOT runtime. It would be hard to guarantee that native linker used to build the application exactly matches the C++ compiler used to compile the runtime .lib files.
• Custom configurations of the unmanaged runtime. For example, compiling the runtime with higher level of security mitigations or with custom versions of system libraries.
• Mismatch in C runtime flavor on Windows (LNK2038 mismatch detected in NativeAOT #85517)

We have introduced options to compile OpenSSL shims and ICU shims at application build time. This issue is about extending this approach to all native AOT unmanaged runtime code.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Native AOT compiler package includes precompiled libraries (.lib/.a files) with unmanaged runtime code. This works well in most cases. However, we have

• LTCG optimization for unmanaged runtime code. LTCG optimizations require exact match between C++ compiler and native linker versions, that prevents us from enabling this optimization for native AOT runtime. It would be hard to guarantee that native linker used to build the application exactly matches the C++ compiler used to compile the runtime .lib files.
• Custom configurations of the unmanaged runtime. For example, compiling the runtime with higher level of security mitigations or with custom versions of system libraries.
   
  We have introduced options to compile OpenSSL shims and ICU shims at application build time. This issue is about extending this approach to all native AOT unmanaged runtime code.

Author:	jkotas
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[MichalPetryka]

One issue with this I guess is that it'd introduce a dependency on Clang on Linux systems, since GCC is not officially supported.

[jkotas]

Yes, it would have almost the same pre-reqs as dotnet/runtime repo build: https://github.com/dotnet/runtime/blob/main/docs/workflow/requirements/linux-requirements.md#toolchain-setup (with a few exceptions - curl, git, lldb and ninja should not be necessary).

[jkotas]

From #102586 (comment) (@jkoritzinsky)

For this scenario, we should produce simple and straightforward CMake files that have the minimal information required to define the CMake targets necessary to build the libraries. Right now we have a decent amount of logic that's shared with the rest of the runtime repo (functions, shared definitions), and I don't think we want to ship our eng/native directory.

[jkotas]

From #102586 (comment) (@MichalStrehovsky)

I've looked at this in the past, and yeah, the shared CMake files don't make it easy to disconnect from our engineering system. But if we don't use the same files that we use to build the product, it's super easy to forget switches/ifdefs and end up with a different runtime, that could be different in very subtle ways. It also doesn't help that CoreLib relies on files we generate as part of native build and who knows if they could be different.

[sweemer]

From #102586 (comment) (@jkoritzinsky)

For this scenario, we should produce simple and straightforward CMake files that have the minimal information required to define the CMake targets necessary to build the libraries. Right now we have a decent amount of logic that's shared with the rest of the runtime repo (functions, shared definitions), and I don't think we want to ship our eng/native directory.

In addition to defining the CMake targets necessary to build the libraries, it would be great to go the other way as well and somehow generate MSBuild .props or .targets from the user's CMake configuration. This would ensure that the same linker options are used for both linking the native library and then statically linking it with Native AOT.

That is, all of the linker flags my native library uses (whether defined by CMAKE_CXX_FLAGS or by target_link_options) should ideally be added as LinkerArg properties to a .targets or .props file that my Native AOT project automatically consumes.

This technique was suggested to me in #108009 (comment) and it works well - the only problem is that there is nothing to enforce consistency between the linker flags in my CMakeLists.txt file and .targets file. It would be great if the .NET SDK could provide this functionality.