Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
The bug manifests like this: > Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded. which happens because the SBNotificationHub doesn't exist in the final executable. We asked the linker to link with the static library containing this type, but the linker didn't link with the library because it didn't need any of the symbols in it. We should have collected all the exported Objective-C types from this library and asked the native linker to keep them, but that didn't happen because: 1. We collect bound Objective-C classes from binding libraries here (the ListExportedSymbolsStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs#L148-L157 2. That only happens for attributes with a LinkWith attribute. * We compute if an assembly has a LinkWith attribute here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L266 * Which is called from here: https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/common/Assembly.cs#L198 * Which is called from here (the ExtractBindingLibrariesStep): https://github.com/xamarin/xamarin-macios/blob/608765e2c9e474c494958844a94354f90fa42f36/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs#L18 Now, we must obviously compute if an assembly has a LinkWith attribute before doing anything that depends on that value, but we weren't doing things in that order. Changing the custom linker steps to run the ListExportedSymbols step *after* the ExtractBindingLibrariesStep fixes this logic problem. Fixes #17347.
- Loading branch information
This comment was marked as outdated.
Sorry, something went wrong.