* Pass -Wl,-no_weak_imports to the linker so that we don't accidentally use
symbols weakly. This would cause problems on older OSes where the symbol
isn't there, because our code is not prepared to deal with weakly linked
symbols.
* Manually disable fstatat and readlinkat (introduced with Xcode 7 in iOS 8 /
macOS 10.10), found by the above.
* Manually disable __thread support for a few targets, since mono's configure
script doesn't properly detect it's not supported.
* Manually disable clock_nanosleep, since mono's configure script doesn't
properly detect it's not supported.
* Bump Mono to mono-4.8.0-branch commit 9437553e545f57443ccc33fe4129cbb6ac94f832.
* Rename MobileCertificateHelper -> AppleCertificateHelper.
All the non-Apple-specific functionality now lives in System.dll's
MobileTlsContext, so it can be shared with BTLS.
* Remove old src/Security/Tls sources which have been moved into System.dll
a couple of weeks ago.
* [msbuild] Set $(CscDebugFileExt) also, whenever overriding $(CscToolExe)
- This property was introduced in mono's msbuild, but will be upstream
also
- This *must* be set before Microsoft.CSharp.targets file is imported.
- Even though the msbuild targets will automatically select `.mdb` if
the `$(CscToolExe)` is `mcs` or `mcs.exe`, it would be a good
practice to set both the properties together.
- This came up in cases where we use `smcs`, because in that case the
msbuild targets end up using `.pdb`.
* [msbuild] Set `$(CscDebugFileExt)` == `.mdb`
Xamarin.ObjcBinding.CSharp.targets: Set the debug file extension also,
since we are overriding the compiler via `$(CscToolExe)`. Also, move
the property definition around to ensure that they are set *before*
importing `Microsoft.CSharp.targets`.
The MT2001 error is a general, something went bad, in the linker code
base. The stack trace is often enough to track down issues but in some
cases it would be easier to ask customers for a specific assembly
(rather than their complete project) to investigate an issue.
Example:
error MT2103: Binding Optimizer failed processing `System.Void GoogleConversionTracking.Unified.GoogleConversionPing::.ctor()`.
--- inner exception
System.NullReferenceException: Object reference not set to an instance of an object
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessIsDirectBinding (Mono.Cecil.MethodDefinition caller, Mono.Cecil.Cil.Instruction ins) [0x00026] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:264
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.ProcessCalls (Mono.Cecil.MethodDefinition caller, Int32 i) [0x00337] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:197
at MonoTouch.Tuner.OptimizeGeneratedCodeSubStep.Process (Mono.Cecil.MethodDefinition method) [0x0007b] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/MonoTouch.Tuner/OptimizeGeneratedCodeSubStep.cs:81
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00004] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:48
---
at Xamarin.Linker.StateSubStep.ProcessMethod (Mono.Cecil.MethodDefinition method) [0x00014] in /Users/poupou/git/xamarin/xamarin-macios/tools/linker/CoreOptimizeGeneratedCode.cs:50
at Mono.Tuner.SubStepDispatcher.DispatchMethod (Mono.Cecil.MethodDefinition method) [0x0001d] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:215
at Mono.Tuner.SubStepDispatcher.BrowseMethods (ICollection methods) [0x0001c] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:167
at Mono.Tuner.SubStepDispatcher.BrowseTypes (ICollection types) [0x0006b] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:145
at Mono.Tuner.SubStepDispatcher.BrowseAssemblies (IEnumerable`1 assemblies) [0x00050] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:123
at Mono.Tuner.SubStepDispatcher.Process (Mono.Linker.LinkContext context) [0x0000f] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/tuner/Mono.Tuner/Dispatcher.cs:104
at Mono.Linker.Pipeline.Process (Mono.Linker.LinkContext context) [0x00027] in /Users/poupou/git/xamarin/xamarin-macios/external/mono/mcs/tools/linker/Mono.Linker/Pipeline.cs:118
at MonoTouch.Tuner.Linker.Process (MonoTouch.Tuner.LinkerOptions options, MonoTouch.Tuner.MonoTouchLinkContext& context, System.Collections.Generic.List`1& assemblies) [0x000ac] in /Users/poupou/git/xamarin/xamarin-macios/tools/mtouch/Tuning.cs:79
Right now the MT2001 would only include the inner exception, which does
not include any clue to which assembly caused the exception.
Note: The same pattern to be applied to other BaseSubStep subclasses in
separate commits.
Related to (but not the fix for) https://bugzilla.xamarin.com/show_bug.cgi?id=44701
* mono revision at fc99fc4313e7afd75a4605a48b47e7d1273aefe4
* watch-mono revision is more recent to include the BCL adjustments
for types not available on that platform
* Update two linksdk test cases that won't work _normally_ for watchOS
Some binding assemblies contains extra, unneeded code, generated by the C# compiler, e.g.
IL_002f: stloc.0
IL_0030: ldloc.0
which the binding optimizer did not expect.
https://bugzilla.xamarin.com/show_bug.cgi?id=44701
At startup we send a request to all the IP addresses we have,
so we must make sure to not get confused if we get responses
from more than one of them.
This fix also requires an updated mlaunch.
https://bugzilla.xamarin.com/show_bug.cgi?id=44568
Bump Mono to pickup the BCL part of the fix.
commit 2a3e4002ead94aae6796c7eb7af9a850398beb51
Author: Martin Baulig <martin.baulig@xamarin.com>
Date: Fri Sep 23 17:42:05 2016 +0200
[AppleTls]: Flush the write queue before finishing the handshake.
It is possible for SSLHandshake() to return SslStatus.Success while we're still
having a pending write (AsyncOperationStatus.WantWrite).
This is because our managed write callback must never return 'WouldBlock', so
SSLHandshake() things that all data have been sent while we still have them in
our write queue.
When this happens, we currently flush the write queue then call SSLHandshake()
again via AsyncOperationStatus.WantWrite -> AsyncOperationStatus.Continue.
This returns SslStatus.Protocol on iOS 10.
(cherry picked from commit 2cc1b887c1c6e86b6844116c8010bac3305c84f9)
https://bugzilla.xamarin.com/show_bug.cgi?id=37175
NSUrlSession's Create*Task methods may return an object of the wrong
type (NSUrlSessionTask instead of NSUrl[Data|Download|Upload]SessionTask),
so we need to bypass our type check when creating the managed object,
otherwise we end up throwing InvalidCastExceptions randomly. We will
return the type that is declared on the headers so if the native side
returns a cat and headers says it barks we'll we make it bark :).
https://bugzilla.xamarin.com/show_bug.cgi?id=44322
AVAssetDownloadUrlSession.CreateSession according to headers it
should return an AVAssetDownloadUrlSession but it is returning
an apple internal type NSURLBackgroundSession so with our
current bindings it throws an InvalidCastException, adding
ForcedTypeAttribute will create the managed type wihout
the actual typecheck. Added test verifing that the API
no longer throws.
https://bugzilla.xamarin.com/show_bug.cgi?id=37175https://bugzilla.xamarin.com/show_bug.cgi?id=44322
Sometimes iOS API is returning objects of the wrong type for example
- (NSURLSessionDownloadTask *)downloadTaskWithRequest:(NSURLRequest *)request
It clearly states that it will return an NSURLSessionDownloadTask
instance, but yet it returns a NSURLSessionTask and we throw an
InvalidCastException when creating the managed object. This is
fine in ObjC but for us in a type-safety context is not.
Introducing ForcedTypeAttribute when applying this attribute
we will use GetINativeObject instead of GetNSObject which
the former does not perfom a type check on the underlying object
The nested Parallel.ForEach loops don't take into account the outer
MaxDegreeOfParallelism value, causing us to spawn more concurrent tasks than
we want to.
So refactor the code to have one static list of tasks, which each subtask adds
to.
The nested Parallel.ForEach loops don't take into account the outer
MaxDegreeOfParallelism value, causing us to spawn more concurrent tasks than
we want to.
So refactor the code to have one static list of tasks, which each subtask adds
to.
* Fix default http message handler for watchOS.
Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).
* [tests] Remove explicit http client handler from project files.
Just use the default instead, since the set of valid http client handlers varies between platforms.
We've used the dynamic registrar for years now when selecting the IL registrar
(and I've never heard about anybody doing it), so just remove all the related
(and in fact dead) code.
New enum UIFontTextStyle maps to UIFontTextStyle* fields. Allows easier use of
* UIFont.GetPreferredFontForTextStyle
* UIFontDescriptor.GetPreferredDescriptorForTextStyle
https://bugzilla.xamarin.com/show_bug.cgi?id=42967
Rolf Bjarne Kvinge
Sebastien Pouliot
Martin Baulig
Ankit Jain
Alex Soto
Chris Hamons
Alex Soto
Alexander Köplinger
Jeffrey Stedfast
Artur Shamsutdinov
Manuel de la Pena
Zoltan Varga