-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Remove _init and _fini exports from NAOT and update android docs #100755
Conversation
The last NDK I used was 26 with NativeAOT-AndroidHelloJniLib was 26, I just avoid these LinkerArg elements. |
Doing some investigation, I don't think the older workaround was appropriate at all.
(Note however, In more "standard" glibc Linux (and presumably also musl?), you'd get The proper fix here is to just not put |
Thanks for the further research @CasualPokePlayer, very thorough! If the signatures are mismatched, then this workaround makes more sense than the old one. I'll mark the PR ready for review. As to the fix: @josephmoresena, since you added it the global symbols in export list (long time ago), dotnet/corert@88d7571#diff-c9020f726343209ae19211774789db0cb46bcc828f448c07ef62cb6a552b93a8R49 (current location in this repo: |
IIRC, it just would not work without that line (the global constructors/destructors would not run). If the shared libraries stil work with that line deleted, I do not see a problem with deleting it. |
@jkotas, seems like _init and _fini are not exported in case of .so, only when it is executable. Removing them from version file seems safe (init/fini are obsolete and we should be using |
This can use |
Thanks for the help guys, I've been busy so I can't really test this right now, but it looks like you got this! |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
@CasualPokePlayer found an alternative workaround to publish apps with latest NDK (LTS): #92272 (comment)
@josephmoresena, @LittleCodingFox, could you please confirm if this works with your setup (presumably with older NDK)? If not, we can keep both workarounds in the docs for now and later we can look into implementing small introspection to detect either-or cases in BuildIntegration to automate it.
Fixes #92272