Add support for consuming the selected Mono components correctly #12100
Assignees
Labels
Milestone
Comments
rolfbjarne
added
dotnet
rolfbjarne
changed the title
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Jul 26, 2021
…ng statically. Fixes dotnet#10950, dotnet#11145 and dotnet#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 dotnet#10950. Fixes dotnet#11145. Fixes dotnet#12100.
rolfbjarne
added a commit
to rolfbjarne/xamarin-macios
that referenced
this issue
Aug 2, 2021
…ng statically. Fixes dotnet#10950, dotnet#11145 and dotnet#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 dotnet#10950. Fixes dotnet#11145. Fixes dotnet#12100.
rolfbjarne
added a commit
that referenced
this issue
Aug 3, 2021
…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.
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Ref: dotnet/runtime#54417
Ref: dotnet/runtime#54432
This will likely be required in a .NET bump at some point.
The text was updated successfully, but these errors were encountered: