-
Notifications
You must be signed in to change notification settings - Fork 517
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
[net6] iOS release binaries are dynamically linking to .dylib #11145
Comments
…builds The original goal was to remove the `.dylib` from the app bundle. However some are required, even in release, so that will need to be fixed first [1] [1] xamarin#11145
The underlying cause is tracked by #10950. UPD: Hmm, maybe I spoke too fast. On iOS the dllmap API should likely still do the job. |
Turns out I wasn't too far off. The calls to mono_dllmap_insert don't actually work because the name doesn't match the one used in the managed code. The managed code requires the The fallback path should not be hit at all though. It's the System.Native symbols not present in the main executable (verified with empty output of |
And the last missing piece is that this code doesn't account for the So, in summary:
|
@filipnavara interesting approach. You're using the override to get the dynamic linking resolved into the main executable. I'm not sure if that works with bitcode (for tvOS). IIRC what we've been doing (until recently) is having the It would be interesting to compare both (build perf, runtime perf and size) but I'm be happy to start your PR 😄 |
Technically it would be possible to build the dotnet/runtime with |
…ng statically. Fixes xamarin#10950, xamarin#11145 and xamarin#12100. * Add support for Mono Components. * Modifies how we look up symbols from native libraries shipped with Mono: This also meant propagating how libmono is linked from the MSBuild code to the Application class so that our existing logic is able to correctly determine which native mono lib to use. Fixes xamarin#10950. Fixes xamarin#11145. Fixes xamarin#12100.
…ng statically. Fixes xamarin#10950, xamarin#11145 and xamarin#12100. * Add support for Mono Components. * Modify how we look up symbols from native libraries shipped with Mono: we keep track of which native libraries we linked with, and depending on how we linked to those assemblies, we look the symbols up at runtime in either the current executable (if linking statically), or the actual library (where the P/Invoke says they're supposed to be). * This means that we have to propagate how libmono is linked from the MSBuild code to the Application class so that our existing logic is able to correctly determine which native mono lib to use. * Modify how we list the P/Invokes we need to preserve by taking into account the list of native libraries from Mono we have to link with (for .NET). For legacy Xamarin, I've reverted the logic to how it was before we started adding .NET support. Fixes xamarin#10950. Fixes xamarin#11145. Fixes xamarin#12100.
…ng statically. Fixes #10950, #11145 and #12100. (#12323) * Add support for Mono Components. * Modify how we look up symbols from native libraries shipped with Mono: we keep track of which native libraries we linked with, and depending on how we linked to those assemblies, we look the symbols up at runtime in either the current executable (if linking statically), or the actual library (where the P/Invoke says they're supposed to be). * This means that we have to propagate how libmono is linked from the MSBuild code to the Application class so that our existing logic is able to correctly determine which native mono lib to use. * Modify how we list the P/Invokes we need to preserve by taking into account the list of native libraries from Mono we have to link with (for .NET). For legacy Xamarin, I've reverted the logic to how it was before we started adding .NET support. Fixes #10950. Fixes #11145. Fixes #12100.
see
dotnet/targets/Xamarin.Shared.Sdk.targets
This copies all
.dylib
into the final app bundle (.app).This greatly increase the size of the
.app
since there are duplicates and all (or at least part) of the code is also statically linked into the main executable binary. This is visible from the reports included in #10249This is not allowed by App Store rules (dynamic linking is only possible to user frameworks, not
dylib
).Note: Removal of the
.dylib
leads to crash at runtime so there is dynamic linking being done.The text was updated successfully, but these errors were encountered: