37c11cf0a1
Stop requiring a LinkWith attribute in an assembly in order to keep any Objective-C
types within. There are many ways to include a native library in a build nowadays,
and more and more often they don't need any LinkWith attributes to specify custom
linker behavior (in particular for frameworks, which can typically be included as-is).
The result of not searching such assemblies for Objective-C types would be that the
native linker would strip them away, and that would mean incorrect behavior at runtime.
However, this is a rather invasive change, especially for a minor release, so I'm
adding two things to make it better:
1. An opt-out MSBuild property: `RequireLinkWithAttributeForObjectiveCClassSearch`.
Set to 'true' to opt-out (default is 'false').
2. Improve handling of native symbols with regards to the native linker.
Add a new item group, ReferenceNativeSymbol, that contains native symbols
we handle in some way - either to be ignored or we ask the native linker
to keep it (by passing it as '-u ...' or in a symbol list file).
There are two supported types of metadata:
* SymbolType: either 'ObjectiveCClass', 'Function' or 'Field'. Used to
compute the complete native name of a symbol (for instance, the native
symbol for the Objective-C class "MyClass" is `_OBJC_CLASS_$_MyClass`,
while for a function "MyFunction" it's just `_MyFunction`.
* SymbolMode: either 'Ignore' or 'Default'. "Ignore" means to not pass the given
symbol to the native linker, the default is to do so.
SymbolType is required, while SymbolMode isn't.
Example symbol to keep:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" />
</ItemGroup>
```
Example symbol to ignore:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" SymbolMode="Ignore" />
</ItemGroup>
```
Finally use the latter solution to work around an issue that arouse with monotouch-test:
we reference an Objective-C class that doesn't exist in monotouch-test. This worked
because the referencing assembly didn't have a LinkWith attribute (and thus the reference
was ignored), but now that the reference isn't ignored anymore, we need to explicitly
ignore the Objective-C class.
|
||
|---|---|---|
| .. | ||
| MonoTouch.Tuner | ||
| ApplyPreserveAttribute.cs | ||
| BaseProfile.cs | ||
| ChangeLog | ||
| CoreHttpMessageHandler.cs | ||
| CoreMarkStep.cs | ||
| CoreOptimizeGeneratedCode.cs | ||
| CorePreserveCode.cs | ||
| CoreRemoveAttributes.cs | ||
| CoreRemoveSecurity.cs | ||
| CoreSweepStep.cs | ||
| CoreTypeMapStep.cs | ||
| CustomSymbolWriter.cs | ||
| ExceptionalSubStep.cs | ||
| MarkNSObjects.cs | ||
| MobileApplyPreserveAttribute.cs | ||
| MobileExtensions.cs | ||
| MobileMarkStep.cs | ||
| MobileProfile.cs | ||
| MobileRemoveAttributes.cs | ||
| MobileResolveMainAssemblyStep.cs | ||
| MobileSweepStep.cs | ||
| ObjCExtensions.cs | ||
| README.linker | ||
| RegistrarRemovalTrackingStep.cs | ||
| RemoveRejectedTypesStep.cs | ||
| RemoveSelectors.cs | ||
| RemoveUserResourcesSubStep.cs | ||
| ScanTypeReferenceStep.cs | ||
README.linker
README.linker Q: Why some stuff is not linked out ? A: In most case this is because: a) the BCL uses it internally b) the mono runtime depends on the type, methods, class layout = mscorlib.dll = System.Security.PermissionSet * Assembly has (3) fields of that type * mscorlib.xml preserve all fields from Assembly (object-internals.h) * code is "stubified" by the linker System.Security.Policy.ApplicationTrust: * Used as a field in AppDomainSetup; * Field also exists in unmanaged code (domain-internals.h); * mscorlib.xml preserve all fields from AppDomainSetup * only the default .ctor remains and is stubified by the linker System.Security.Policy.Evidence * Used by AppDomain.Load[Assembly] * Used by Assembly.LoadWithPartialName overloads * code is "stubified" by the linker = System.dll = System.Text.RegularExpressions.* * Included because there is 2 regex in UriParser