[native] Runtime linking at app build time #9006
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
4 times, most recently
from
bf5c35a
to
bfedf30
Compare
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
4 times, most recently
from
9a604d3
to
9fc5594
Compare
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
3 times, most recently
from
7f5c98e
to
57ab585
Compare
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
4 times, most recently
from
58f17e2
to
6f5f5c6
Compare
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
2 times, most recently
from
68ab1b7
to
da87011
Compare
grendello
added a commit
that referenced
this pull request
Jul 24, 2024
Context: #9006 This commit prepares ground for dynamic native runtime linking at application build time by moving code around and making it more modular, thus allowing the on-build linking of the runtime to work properly. In particular, this applies to the `p/invoke` handling code which is going to be different between the pre-linked (and shipped) runtime and the one linked on demand during application build. The difference lies in the fact that on-demand build will scan the application for p/invoke usage (after trimming) and will only include functions that are actually called from the managed land. Results of the scan will be used to generate LLVM IR code at build time that references the required functions, which will allow the native linker to remove the remaining ones. Changes implemented here can be committed to `main` and, possibly, released with .NET9 without changing how things currently work.
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
6 times, most recently
from
5f35bf1
to
99baef4
Compare
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
from
99baef4
to
6d17643
Compare
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
3 times, most recently
from
9ed6397
to
4d17d92
Compare
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
from
92da875
to
813c444
Compare
The "hello world" apps size decrease: * ~2 meg for XA * ~1.8 meg for MAUI
It seems `$(AndroidIncludeDebugSymbols)` isn't defined yet by the time `src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultProperties.targets` is evaluated, so we need to move `$(_AndroidEnableNativeRuntimeLinking)` to src/Xamarin.Android.Build.Tasks/Xamarin.Android.Common.targets in order to disable linking in Debug builds.
MonoVM requires `libunwind.a` on x86_64. Until the requirement is removed, we'll include the archive. dotnet/runtime#107615
Otherwise `<FileWrites>` in `_CompileNativeAssemblySources` won't actually get written to the cache and the `GenerateJavaStubsAndAssembly` test fails.
They might contain nested types with interesting methods. Doh.
Unconditionally disable dynamic linking in the AOT profiling test
Testing just a single configuration, it's enough.
grendello
force-pushed
the
dev/grendel/runtime-link-at-build
branch
from
7503400
to
81a7369
Compare
grendello
added a commit
to grendello/runtime
that referenced
this pull request
Nov 25, 2024
In dotnet/android#9006 we are working on linking the .NET for Android runtime dynamically at the application build time. Linking involves all the BCL native libraries, including `System.Security.Cryptography.Native.Android` and one of the goals is to hide all the exported symbols used as p/invokes by the managed BCL libraries. This is because p/invoke calls are handled internally and, with dynamic linking of the runtime, there is no longer any reason to use `dlopen` and `dlsym` to look them up, they are all resolved internally, at the link time. Symbol hiding works fine thanks to the `--exclude-libs` `clang` flag, which makes all the exported symbols in the indicated `.a` archives to not be exported by the linker. However, `System.Security.Cryptography.Native.Android` is special in the sense that it contains one symbol which must not be hidden, `Java_net_dot_android_crypto_DotnetProxyTrustManager_verifyRemoteCertificate`. The above function is a Java `native` method implementation, and it requires that not only its name follows the Java JNI naming rules, but that is also available for the JVM to look up using `dlsym`. I tried using the `--export-dynamic-symbol` clang flag to export **just** this function, but it doesn't appear to work no matter where I put the flag in relation to reference to the `.a` archives. Instead, the problem can be dealt with by putting the JNI function in a separate static library, so that I can link it without changing symbol visibility, while making all the `System.Security.Cryptography.Native.Android` symbols invisible.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.