Delete NativeAOT_StaticInitialization

[MichalStrehovsky]

Undoes workaround from dotnet/runtimelab#270. Since bootstrapper no longer ships as a static library (as of #74623 it's an object file instead), we should no longer need this hack to force linker into looking at the archive.

Cc @dotnet/ilc-contrib

[ghost]

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

Issue Details

---

Undoes workaround from dotnet/runtimelab#270. Since bootstrapper no longer ships as a static library (as of #74623 it's an object file instead), we should no longer need this hack to force linker into looking at the archive.

Cc @dotnet/ilc-contrib

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

[filipnavara]

I'm pretty sure that the Xamarin integration relies on this. We definitely need to double-check before merging.

[MichalStrehovsky]

I'm pretty sure that the Xamarin integration relies on this. We definitely need to double-check before merging.

I suspected that but a search in the dotnet organization on github found no hits for that outside this repo and samples repo.

[filipnavara]

I suspected that but a search in the dotnet organization on github found no hits for that outside this repo and samples repo.

It's not about a hit for the function name (NativeAOT_StaticInitialization). It's about the CustomNativeMain=true condition which should ensure that the runtime is initialized early on through a static C++ constructor, and ensuring that the constructor (and in fact the whole .o file) doesn't get linked out.

[MichalStrehovsky]

I think that's the same problem that this was working around. The sole reason for this symbols existence is that the linker didn't even bother looking into the .a file because nothing was needed from it. Since it's now an .o file, the linker will open it. We have tests for CustomNativeMain in this repo (and SharedLibrary as well) that would fail if this got broken. I tested on Linux and it's not broken. Waiting for CI to test Windows.

[filipnavara]

I mean, there's a chance that you are right and it's no longer necessary. I just feel that it should be tested with the Xamarin scenario since it doesn't use the same linker steps.

[ivanpovazan]

I will verify this with Xamarin and post the update.

[jkotas]

We should update the docs at https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary#building-static-libraries once this is merged.

[MichalStrehovsky]

We should update the docs at https://github.com/dotnet/samples/tree/main/core/nativeaot/NativeLibrary#building-static-libraries once this is merged.

dotnet/samples#6026

[ivanpovazan]

Verified that this change does not break Xamarin integration.

[filipnavara]

Thanks for verifying. I checked that the runtime packs contain the .o files, so we should be good 👍