Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delete NativeAOT_StaticInitialization #89291

Merged
merged 1 commit into from
Jul 25, 2023

Conversation

MichalStrehovsky
Copy link
Member

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

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

ghost commented Jul 21, 2023

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
Copy link
Member

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

@MichalStrehovsky
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

I will verify this with Xamarin and post the update.

@jkotas
Copy link
Member

jkotas commented Jul 23, 2023

@MichalStrehovsky
Copy link
Member Author

@MichalStrehovsky MichalStrehovsky merged commit 119667b into dotnet:main Jul 25, 2023
106 checks passed
@MichalStrehovsky MichalStrehovsky deleted the naturalinit branch July 25, 2023 00:56
@ivanpovazan
Copy link
Member

Verified that this change does not break Xamarin integration.

@filipnavara
Copy link
Member

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

@ghost ghost locked as resolved and limited conversation to collaborators Aug 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants