The nice, repeatable test case from #7514 pointed out two issues
1. `cache.cs` ignored some changes
It looks like something changed (at some point) and the first _ignored_
line was the `@x.rsp` our response file - which should not be ignored.
This solved the build issue where updating the nuget should have
triggered a rebuild because
> /Users/poupou/.nuget/packages/skiasharp/1.68.0/lib/Xamarin.iOS/SkiaSharp.dll
and
> /Users/poupou/.nuget/packages/skiasharp/1.68.1/lib/Xamarin.iOS/SkiaSharp.dll
are different assemblies (but the same response file).
2. `copyfile` could fail silently
Copying the framework could fail (error 260) and the failure was never
reported so the build succeeded - but without updating (completely) the
framework.
The exact reason it fails is unknown :( but we can recover from it by
deleting the target and copying (everything) back to the expected
(target) location.
Build logs will now indicate when this fails and will try to recover
before reporting a build error. Best case it works :) worse case we'll
be aware something is wrong (which is better than ignoring)
ref: https://github.com/xamarin/xamarin-macios/issues/7514
* Do not call `Marshal.GetLastWin32Error` instead the callback
as the `SetLastError` logic has yet to be executed so we get a bogus
`260` value...
Instead we call it after the `copyfile` call returns but, at this stage,
the callback (i.e. **us**) signaled an error so what we get back (`17`)
is not very helpful - as we aborted (Quit) the logic when copying a file
that existed.
```c
#define EEXIST 17 /* File exists */
```
from Console logs
```
default 14:23:54.771292-0500 mono64 Cannot make directory /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework: File exists
default 14:23:54.771620-0500 mono64 Cannot make directory /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework/_CodeSignature: File exists
default 14:23:54.771850-0500 mono64 open on /Users/poupou/Projects/gh7514/gh7514/bin/iPhoneSimulator/Debug/gh7514.app/Frameworks/libSkiaSharp.framework/_CodeSignature/CodeResources: File exists
```
`copyfile.c` source code (might not be the latest) can be seen from
https://opensource.apple.com/source/copyfile/copyfile-42/copyfile.c
```c
if (mkdir(s->dst, mode) == -1) {
if (errno != EEXIST || (s->flags & COPYFILE_EXCL)) {
copyfile_warn("Cannot make directory %s", s->dst);
```
so `mkdir` fails - but not because of `EEXIST` and from `copyfile.h`
we see that `EXCL` exists but it's not using (or even defined) in our
bindings.
```c
#define COPYFILE_EXCL (1<<17) /* fail if destination exists */
```
So sadly the `Err` condition (inside the callback) does not give us more
detail about the error itself.
## Miscellaneous fixes
* Fixed
`/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/external/linker/src/linker/Linker.Steps/OutputStep.cs(110,15): error CS0246: The type or namespace name ‘OutputException’ could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/mmp/mmp.csproj]`
* Changed the name of the method that is used from linker. Because of this commit 6be26771b9
* Added `OutputException.cs` file on `mtouch.csproj`.
* Removing enter_gc_safe and exit_gc_safe because now it's already gc_safe in this part of code, after a mono change.
* Added known exceptions to LLVM exception list.
* Needs `ifdef` because of this https://github.com/mono/mono/pull/17260.
* Bump MIN_MONO_VERSION to 6.8.0.41 and point MIN_MONO_URL to the PR.
* Add ENABLE_IOS=1 and ENABLE_MAC=1.
* Added switch to disable packaged mono build
* [Tests] Ignore tests that fail on 32b.
Ignore the test on 32b, and filled issue: https://github.com/mono/mono/issues/17752
* [Tests] Ignore a couple of tests causing OOM.
Hopefully fixes https://github.com/xamarin/maccore/issues/1659 for good.
* Ignore `MM0135` test on Catalina+ because it needs Xcode 9.4.
* [monotouch-test] Add null checks for teardown when test didn't run because of a too early OS version.
* [CFNetwork]: Http 2.0 requires OS X 10.11 or later.
Check whether `_HTTPVersion2_0` is available and fallback to HTTP 1.1 otherwise.
## Bring HttpClient from CoreFX
* #7346
* This bumps Mono to use https://github.com/mono/mono/pull/17645 (which is the 2019-10 backport
of https://github.com/mono/mono/pull/17628).
* The big user-visible change is in regards to certificate validation, everything below are just
some minor adjustments to tests.
### SocketsHttpHandler
CoreFX uses a completely new `HttpClientHandler` implementation called `SocketsHttpHandler`,
which you can find at https://github.com/dotnet/corefx/tree/release/3.0/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler.
Since this is not based on the web stack anymore, it does not use any of the related APIs such
as `ServicePointManager` or `WebException`.
### Certificate Validation Changes
There is a new API called `HttpClientHandler.ServerCertificateCustomValidationCallback`.
- https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback?view=netframework-4.8
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs (L154)
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Windows.cs (L383)
The `ServicePointManager.ServerCertificateValidationCallback` is no longer invoked and on
certificate validation failure, `AuthenticationException` (from `System.Security.Authentication`)
is thrown instead of `WebException`.
At the moment, the `NSUrlSessionHandler` still uses it's own validation callback and also still
throws `WebException` on failure; we should probably look into making this consistent with the
other handlers.
### Minor adjustments related to internal Mono APIs
* `HttpContent.SerializeToStreamAsync()` is now `protected` (changed from `protected internal`).
- src/Foundation/NSUrlSessionHandler.cs: changed overload accordingly.
- src/System.Net.Http/CFContentStream.cs: likewise.
* `HttpHeaders.GetKnownHeaderKind()` is an internal Mono API.
There is a new internal API called `System.Net.Http.PlatformHelper.IsContentHeader(key)`
which exists in both the old as well as the new implementation.
The correct way of doing it with the CoreFX handler is
`HeaderDescriptor.TryGet (key, out var descriptor) && descriptor.HeaderType == HttpHeaderType.Content`
### Minor adjustments to tests.
* `HttpClientHandler.MaxRequestContentBufferSize` is now longer supported, you can set it to
any non-negative value, the getter will always return 0.
See c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Core.cs (L18).
- tests/linker/ios/link sdk/HttpClientHandlerTest.cs: removed assertion from test.
* `HttpMessageInvoker.handler` is a `protected private` field - in the CoreFX handler, it is
called `_handler` and `private`. This is accessed via reflection by some of the tests, which are
now using the new name.
- tests/mmptest/src/MMPTest.cs: here
- tests/mtouch/MTouch.cs: here
* tests/monotouch-test/System.Net.Http/MessageHandlers.cs:
Adjust `RejectSslCertificatesServicePointManager` to reflect the certificate validation
changes described above.
- FIXME: There was an `Assert.Ignore()` related to `NSUrlSessionHandler` and macOS 10.10;
I removed that to reenable the test because the description linked to an old issue in
the private repo that was referenced by several "Merged" PR's, so it looked to me that
this might have already been fixed - and I also didn't see why it would fail there.
Keep 'CallContextSecurityData' around since it's quite small (and the
normal linker logic will be able to deal with it if unused) and allows
the use of `Thread.CurrentPrincipal`
Also add unit test.
Fix https://github.com/xamarin/xamarin-macios/issues/7321
Turn older #7165 prototype into an experimental feature. It can be
enabled by adding `--optimize=experimental-xforms-product-type` to the
**Additional mtouch arguments** of the project.
ref: https://github.com/xamarin/xamarin-macios/pull/7165
Turn older #7165 prototype into an experimental feature. It can be
enabled by adding `--optimize=experimental-xforms-product-type` to the
**Additional mtouch arguments** of the project.
ref: https://github.com/xamarin/xamarin-macios/pull/7165
The latest SDK version and the latest OS version does not necessarily have to
match (for instance the iOS 13.2 SDK can support both iOS 13.2 and iOS 13.3),
so keep track of them separately.
Also use the latest OS version to determine which simulator to run, instead of
the latest SDK version (Xcode 11.3 ships with the iOS 13.2 SDK but only has an
iOS 13.3 simulator, not an iOS 13.2 simulator).
Fixes https://github.com/xamarin/maccore/issues/2066.
* Bump for Xcode 11.3 beta 1
* [system-dependencies] Make it clearer what failed on the bots.
Locally we use colors to distinguish between warnings and failures, but colors
don't show up on the bots, so use text instead.
* Verbose provisioning.
* [system-dependencies] Improve simulator checks a bit.
* Non-verbose provisioning.
* [Packaging] Ensure that when we build from source, the srcs go to the correct plance.
When building from source, the install-sources command was not moving
the files correctly. This change makes sure that, if we build from
source, we do add the mono sources in the correct location.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7393
* [Packaging] Ensure that when we build from source, the srcs go to the correct plance.
When building from source, the install-sources command was not moving
the files correctly. This change makes sure that, if we build from
source, we do add the mono sources in the correct location.
Fixes: https://github.com/xamarin/xamarin-macios/issues/7393
The PathManglerFactory was getting confused when building mono from
source again and since it did not find the sources in the download
directory it considered that the path to modify was part of Xamarin.
Now the factory tests first if we are getting a path from the mono
external submodule, if that is the case we know is a mono path and do
the right thing.
Fixes https://github.com/xamarin/maccore/issues/2053
The PathManglerFactory was getting confused when building mono from
source again and since it did not find the sources in the download
directory it considered that the path to modify was part of Xamarin.
Now the factory tests first if we are getting a path from the mono
external submodule, if that is the case we know is a mono path and do
the right thing.
Fixes https://github.com/xamarin/maccore/issues/2053
This is already compiled as ObjC++ but this gives an additional (and
required) hint to some tools that it is Objective C++ code.
This avoid a lot of build errors (under static analysis tools),
most of them not really helpful (a trait shared with many C++ compiler
warnings and errors) except for this one:
```
error: invalid argument ‘-std=c++14’ not allowed with ‘Objective-C’
```
* Add bindings for NSXpcConnection and related types
* Re-add accidentally deleted file
* Typo fix
* Add NSXpcInterface.CreateForType()
* Add MethodInfo-taking overloads to NSXpcInterface
* Add null check
* Mark methods with wrappers as internal
Also fixed a formatting bug that I didn't catch earlier.
* Change NSXPCProxyCreating methods to be strongly typed
I got rid of the NSXpcProxyCreating interface in this change,
because its only user was NSXpcConnection, and I needed to
inline the protocol methods into the class definition so I
could mark them as [Internal].
* Add missing casts
* Add NSXpcConnectionOptions enum
* Convert NSXpcConnection constructor to use new enum
* Remove now-unneeded manual constructor
* Fix bgen warning
* Typo fix
* Fix selector
* Remove incorrect use of BindAsAttribute
Per the docs, this only works for enums backed
by NSNumber and NSValue, not for enums
passed directly as integers.
* Fix duplicated selector errors
* Throw ArgumentException instead of InvalidOperationException
* Extend AppExtension targets to produce XPC services
Rather than create an entirely new set of targets
(that would require VS and VSMac updates to properly
consume), I have decided to use the existing AppExtension
build targets to produce XPC services as well. All the
user must do is set the $(IsXPCService) property to true in
their project file, and the targets will do The Right Thing™.
Note that this support is Mac-only for now; I may need a bit
of help adjusting them to work on for iOS/watchOS/tvOS, as I
am not as familiar with those platforms.
* Copy XPC service bundles into the correct location
* Move IsXPCService property definition to props file
* Don't pass /extension to mmp for XPC service targets
This would cause the XPC service binary to
be linked incorrectly.
* Add NSXpcConnection/NSXpcInterface.cs files to the build
* Fix build
* Fix build
* Add required type parameter requirements
* Fix type parameter requirements
* Fix return type
* Fix return type of NSXpcInterface.CreateForProtocol ()
* Take ownership of the returned object types
* Adjust XPC service mmp invocation
I need to link the XPC service bundle as if it is an app extension, but
I must not use xamarin_mac_extension_main. I added a new flag to make
this possible.
* Change mmp to correctly construct XPC service bundle
* Set the MonoBundleExecutable Info.plist key for XPC services
* Use the runtime to get the protocol
* Make NSXpcInterface.CreateForProtocol() public
The static registrar must be used for Cocoa to accept the protocol
as a valid XPC interface, but that then seems to break resolving
the protocol from the type. I must therefore hard-code the protocol
name in my code, and that requires I make this constructor public.
* Add XpcInterfaceAttribute
See the doc comment in XpcInterfaceAttribute.cs for why
this type is required. The referenced mmp optimizations
will be added in future commits.
* Add XpcInterfaceAttribute to generator build
* Add support for XpcInterfaceAttribute to the generator
* Force static generation of protocols decorated with XpcInterfaceAttribute
* Change how static registrar translates block parameters
Previously, they would always be marshalled as "id".
This would throw off the XPC subsystem, which parses
the block signature to determine the communication
protocol.
* Undo whitespace noise
* Remove unneeded casts
* Add trailing comma
* Use HasAttribute instead of GetCustomAttribute
* Fix style issues
* Bind NSXpcConnection.auditSessionIdentifier
* Address naming feedback
* Make Get/SetAllowedClasses public
IMHO, passing the selector as a string is just as
usable as passing a MethodInfo, and is also less
verbose if you copy/paste the selector string
from the ExportAttribute. There is no reason why
we cannot have both overloads be public.
* Update overload names to match
* Update more overload names to match
* Make mmp --xpc imply --extension
* Reformat if statement
* Fix build
* Conditionalize creation of PlugIns and XPCServices directories
* Add AutoGeneratedName
Co-Authored-By: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Get rid of ProtocolizeAttribute
* Update availability attributes to please xharness
I actually think xharness is wrong here, since the
NSXPCConnection header lists these types as being
available starting in macOS 10.8.
* Update sharpie ignore files to reflect changes
This should fix the xtro-sharpie test failures CI has been reporting.
* Fix MM4105 error generation
* Adjust error message in test to match mmp
I had to change the error text slightly, because the type of the parameter
cannot be determined where the error is thrown anymore. However, the newer
exception message IMO is just as clear.
* Make exception message match test exactly
* Remove outdated copyright header text
* Remove more outdated copyright header text
* Revert changes to MM4105 error generation
I have a more elegant way of fixing this test now.
* Return "id" if Invoke method cannot be found
This fixes the MM4105 error unit test,
without requiring modification to that test.
* Remove redundant availability attributes
* Add DesignatedInitializerAttribute
* Re-add required code to macOS-Foundation.ignore
* Put DesignatedInitializer on the right constructor
* Update xtro-sharpie ignore files
* Bump mono to get archives built with Xcode 11.1.
New commits in mono/mono:
* mono/mono@b601371d5f Update MERP event type to MonoAppCrash
* mono/mono@6184ff007b [2019-08][ci] Use Xcode11.1 and 11.2beta2 for XI/XM Mono SDK builds (#17324)
* mono/mono@8969f2cc99 [2019-08] [merp] Include any managed methods in the 'unmanaged_frames' portion … (#17316)
* mono/mono@3009440108 [2019-08][merp] Don't install SIGTERM handler in EnableMicrosoftTelemetry (#17308)
Diff: df5e13f95d..b601371d5f
* Fix accidental/mysterious/captivating/incorrect merge solution selected by git when merging d16-4/xcode11.1 into master.
Apple decided to expose most (but not all) `CIFilter` using protocols
(instead of weakly named dictionaries). Most of this maps well with
our strong bindings but there are cases where we:
* missing some properties (easy, there were added); or
* used a different types [1] and that requires new members / obsoletion
A few other API were also added in Xcode 11 (nothing in 11.1 or 11.2) and
included in this PR.
New introspection tests were also added to minimize the risk that
the API and generator changes produced incorrect code. This lead
to the finding of some missing API (in particular `Output*` properties)
that were added.
[1] Often ours are better (using `float` for a `bool` value is not
optimal) but we do not have `[BindAs]` for protocols :( to _fix_ them
Note: this replace draft PR https://github.com/xamarin/xamarin-macios/pull/7120 but it's has quite a bit of changes in filter generation (inlining protocols) and that affected bindings too.
* Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process.
mono changed how quotes should be escaped when passed to
System.Diagnostic.Process, so we need to change accordingly.
The main difference is that single quotes don't have to be escaped anymore.
This solves problems like this:
System.ComponentModel.Win32Exception : ApplicationName='nuget', CommandLine='restore '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable/CellCustomTable.sln' -Verbosity detailed -SolutionDir '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable'', CurrentDirectory='/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories', Native error= Cannot find the specified file
at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-08/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778
ref: https://github.com/mono/mono/pull/15047
* Rework process arguments to pass arrays/lists around instead of quoted strings.
And then only convert to a string at the very end when we create the Process
instance.
In the future there will be a ProcessStartInfo.ArgumentList property we can
use to give the original array/list of arguments directly to the BCL so that
we can avoid quoting at all. These changes gets us almost all the way there
already (except that the ArgumentList property isn't available quite yet).
We also have to bump to target framework version v4.7.2 from v4.5 in several
places because of 'Array.Empty<T> ()' which is now used in more places.
* Parse linker flags from LinkWith attributes.
* [sampletester] Bump to v4.7.2 for Array.Empty<T> ().
* Fix typo.
* Rename GetVerbosity -> AddVerbosity.
* Remove unnecessary string interpolation.
* Remove unused variable.
* [mtouch] Simplify code a bit.
* Use implicitly typed arrays.
Several functions were 100% identical except for their signature. However
the signature were over-specialized and simplifying them allows the
(already) present code merge feature to achieve much better results.
Final size impact will vary based on the API used (both the managed and
native linker can remove some) but the more API you use the more likely
the application included duplicate code.
**Before**
`tools/mtouch/Xamarin.iOS.registrar.ios.x86_64.m` has `native_to_managed_trampoline_[1..379]`
```
find tools/ -name Xamarin.*.a | xargs ls -l
-rw-r--r-- 1 poupou staff 4143148 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.full.a
-rw-r--r-- 1 poupou staff 4139052 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.full.x86_64.a
-rw-r--r-- 1 poupou staff 4143160 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.mobile.a
-rw-r--r-- 1 poupou staff 4139064 11 Oct 15:09 tools//mmp/Xamarin.Mac.registrar.mobile.x86_64.a
-rw-r--r-- 1 poupou staff 4521752 11 Oct 15:09 tools//mtouch/Xamarin.iOS.registrar.ios.i386.a
-rw-r--r-- 1 poupou staff 9240416 11 Oct 15:09 tools//mtouch/Xamarin.iOS.registrar.ios.simulator.a
-rw-r--r-- 1 poupou staff 4714336 11 Oct 15:09 tools//mtouch/Xamarin.iOS.registrar.ios.x86_64.a
```
**After**
`tools/mtouch/Xamarin.iOS.registrar.ios.x86_64.m` has `native_to_managed_trampoline_[1..132]`
```
find tools/ -name Xamarin.*.a | xargs ls -l
-rw-r--r-- 1 poupou staff 3723012 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.full.a
-rw-r--r-- 1 poupou staff 3718916 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.full.x86_64.a
-rw-r--r-- 1 poupou staff 3723016 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.mobile.a
-rw-r--r-- 1 poupou staff 3718920 11 Oct 14:57 tools//mmp/Xamarin.Mac.registrar.mobile.x86_64.a
-rw-r--r-- 1 poupou staff 3995520 11 Oct 14:57 tools//mtouch/Xamarin.iOS.registrar.ios.i386.a
-rw-r--r-- 1 poupou staff 8195748 11 Oct 14:57 tools//mtouch/Xamarin.iOS.registrar.ios.simulator.a
-rw-r--r-- 1 poupou staff 4193956 11 Oct 14:57 tools//mtouch/Xamarin.iOS.registrar.ios.x86_64.a
```
This has a couple of advantages:
* It makes it easier to add a catalyst version of these libraries (because it
becomes cumbersome to build for catalyst when the build rules assumes we're
building for both simulator and device).
* It makes it easier to create an xcframework of our libraries, because the
contents in an xcframework is split like this.
See https://github.com/mono/mono/issues/17064.
The 2019-08 version of the fix adds a new assembly with NS2.1 APIs that we stubbed out in 2019-06: System.Data.DataSetExtensions.dll
See https://github.com/mono/mono/issues/17064.
The 2019-08 version of the fix adds a new assembly with NS2.1 APIs that we stubbed out in 2019-06: System.Data.DataSetExtensions.dll
* Drop the Xcode 9.4 dependency. (#7044)
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@beb9a1b182 [sdks] Remove the mac32 build.
* mono/mono@747a919a06 [ci] Make ios/mac sdks archive URL more predictable
* mono/mono@114013096e [ci] Build iOS/Mac Mono sdks archive using Xcode 11
* mono/mono@10a24f3ea1 Implement WriteCore and ReadCore in DeflateStream
* mono/mono@a925846b1f [offsets-tool] Install clang into the user-specific python directory. (#16933)
* mono/mono@fe64a4765e [2019-06] Bump msbuild and sdk versions to 3.0.1xx latest (#16870)
* mono/mono@7293597b90 [corlib] Fix building nunit-lite twice (#16910)
* mono/mono@1648e88687 Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16896)
* mono/mono@a6b5187d76 [metadata] Fix leaks when handling a few attributes (#16675) (#16851)
* mono/mono@7da9a041b3 [2019-06] Bump to mono/corefx@e79cf5b
* mono/mono@2b7050bdf3 [2019-06] Add RenamedEvent* to FSW sources from CoreFX (#16758)
* mono/mono@4f5ed502c6 [msbuild] pick up p4 versions
* mono/mono@f04ee2219d [2019-06][msbuid][roslyn] Bump msbuild and roslyn-binaries to pick up dotnet 3.0.100-p9 toolset
* mono/mono@6b4b99e571 Vtable [i] can be null so this should be check before use it. Fixes#16712
Diff: 7af64d1ebe..beb9a1b182
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* [tests] Don't treat an Xcode with the same major version number as old.
Fixes an issue in the MT0091 test, where it would fail on tvOS because the
test wanted to use an older Xcode, and we could end up returning Xcode 11.0
when the current Xcode is 11.1. Since the test depends on using the OS SDK as
it was designed for (technically using an OS SDK earlier than the latest), it
ended up failing because while the iOS SDK was bumped in Xcode 11.1, the tvOS
SDK was not.
Tweak the watchOS architecture test to build for bitcode when building with
llvm, since that's what's usually done.
Also tweak the MT0145 error message a bit.
Fixes https://github.com/xamarin/maccore/issues/1994.
* [builds] add arm64_32 cross compiler
* [mtouch] force --interpreter on arm64_32 debug mode build
* [mtouch] include debug check for arm64_32 and reflect error codes in documentation
* Drop the Xcode 9.4 dependency.
Also bump mono to get the removal of the mac32 binaries.
New commits in mono/mono:
* mono/mono@70d6903053 [2019-08] [merp] Use a separate program as the hang supervisor. (#16900)
* mono/mono@4bff2b6370 [offsets-tool] Install clang into the user-specific python directory.
* mono/mono@81894ec8ca Implement WriteCore and ReadCore in DeflateStream
* mono/mono@bfbf823ca1 [ci] Remove more XCODE32_DIR usages (#16964)
* mono/mono@ce01b20a4d Add net_4.8.xml to EXTRA_DIST and bump binary-reference-assemblies again
* mono/mono@7a587d7fa6 Add .NET 4.8 reference assemblies (#16912)
* mono/mono@35e454a8f6 [sdks] Remove the mac32 build. (#16936)
* mono/mono@75eb342f53 [2019-08] [System] Make FileSystemWatcher backend non-static (#16926)
* mono/mono@5881981f79 [2019-08] [mini] Add missing membars when initializing rgctx entries (#16909)
* mono/mono@6290b6cd6e Temporarily disable embedded ppdb data decompression (#16911)
* mono/mono@a0e7f9eaf2 [2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (#16886)
* mono/mono@6275840a7f Rename bundle identifier for the various Mono.frameworks we create for Xamarin.iOS. Fixesxamarin/xamarin-macios#7005. (#16901)
* mono/mono@25f6093283 [corlib] Fix building nunit-lite twice (#16895)
* mono/mono@7ec17ba1be [2019-08] [android sdk] Add aprofutil tool (#16884)
* mono/mono@f755f3b539 [metadata] Fix leaks when handling a few attributes (#16850)
* mono/mono@5f9a2db39b [2019-08] Fix infrequent hangs in test-runner. (#16854)
* mono/mono@f31f5ea1f1 [2019-08] [threads] do not convert NULL thread name (#16828)
* mono/mono@20308e6f87 [aot] Do not wrap tool_prefix path when calling strip (#16820)
* mono/mono@cecda47c48 [aprofutil] Add -p and -f options
* mono/mono@824cc12ac3 Bump to mono/corefx@e79cf5b
* mono/mono@b77dc06a7e [aprofutil] Install the tool correctly (#16112)
* mono/mono@1848d78d60 [aotprof-tool] Initial import of AOT profiler tool (#15384)
* mono/mono@da0086e304 [2019-08] Add RenamedEvent* to FSW sources from CoreFX (#16756)
* mono/mono@0297b21b03 [msbuild][roslyn] Bump msbuild and roslyn to pull in new versions (#16768)
* mono/mono@40631e3b9e [2019-08] [aot] move method_addresses to data.rel.so section to avoid text relocations (#16751)
* mono/mono@68b77674e2 Vtable [i] can be null so this should be check before use it. Fixes#16712
* mono/mono@4a0b4f41ed [mini] publish global patches after JitInfo has been added
* mono/mono@7a1f63fde6 [debugger][android] It was not initialising seq_points on MonoCompile on Android, so when was compiling dynamic methods, seq_points wasn't created and we got the assert when try to single step.
Diff: 29b1ac19c9..70d6903053
* [tests] Add a fat macOS dylib for testing purposes.
Add a binary version of a fat macOS dylib (because we can't create one when we
need it since we can't create 32-bit slice anymore).
It was created like this (in tests/test-libraries):
$ cat test.m
int theUltimateAnswer ()
{
return 42;
}
$ /Applications/Xcode94.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang test.m -olibtest.i386.dylib -shared -isysroot /Applications/Xcode94.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -framework Foundation -framework CoreLocation -lz -arch i386
$ lipo -create libtest.i386.dylib .libs/macos/libtest.dylib -output libtest-fat.dylib
* [tests] Adjust XM tests to XM not having fat dylibs anymore.
* [tests] Adjust product tests to some libraries not being fat anymore.
* One more test fix.
We ship a default, pre-built, simlauncher for iOS simulator applications.
This speeds up compilation for the default (non linked) simulator builds
quite a lot (no call to `clang` is needed). However it force us to keep
track of frameworks manually - `mtouch` can track them but requires
calling clang/ld to finish things up (killing the optimization).
It's easy to forget some (new) frameworks since they can be loaded
dynamically (on demand) _most_ of the time. Sadly there are a few cases
where doing so cause (hard to diagnose) problems - so we can't depend
on them being loaded, correctly for us.
The new test case loads the `otool -L` output (make when we build
simlauncher[32|64]-sgen) and compares it with mtouch's GetFramework
logic *and* with our namespaces (which is pretty close, with a few
exceptions, to the framework names). This will make it harder to
forget [weak] frameworks when adding new bindings :)
Fixes https://github.com/xamarin/xamarin-macios/issues/6951
* [registrar] Report a warning when the registrar export an abstract INativeObject type to Objective-C.
Exporting abstract types to Objective-C can lead to problems when at runtime
we're asked to create an instance of such a type (which we can't), so warn
when this happens.
This would have caught #6655, and the problems explained in #4969 as well.
Since this may trigger for code that's currently working fine, I'm making it a
warning instead of an error (which means adding some extra code to be able to
easily report warnings from the generator code).
* Don't assume a TypeReference can be successfully resolved every time.
Included changes are:
* New Cecil API in 2019-08
* Permit new symbols from networkable AOT profiler in symbols test
* Bump Mono to include fix for zlib linking, and new Cecil API
* We need to link against zlib now, if using libmono.a
* [Tests] Ignore memory hungry tests in old devices. (#6913)
* Ignore certain tests that use too many resources in old devices.
* Add missing tests that use too much memory on 32b devices.
* Add a dummy x86_64 slice to all our native libraries that don't have one. (#6848)
Apple's notarization tool has a bug where they incorrectly flag Mach-O
binaries without an x86_64 slice, so make sure all our libraries have one.
* Jenkinsfile notarization (#6869)
* Add in notarization script for xamarin.mac/xamarin.iOS
* Flatten the list to get rid of the braces
* Add in keychain password
* Add login.keychain back in to access codesigning certificates
* Always sign pkgs, upload notarized copies
* Enable ios notarization and make notarized pkgs public
* Make notarization non-fatal
* Publish GH statuses for notarized PKGs
* Don't forget to declare URI variables for notarized pkgs
* report proper package links
* [jenkins] Improve package reporting.
* Use dummy function name which our tests won't complain about.
* Add a dummy x86_64 slice to all our native libraries that don't have one. (#6848)
Apple's notarization tool has a bug where they incorrectly flag Mach-O
binaries without an x86_64 slice, so make sure all our libraries have one.
* Jenkinsfile notarization (#6869)
* Add in notarization script for xamarin.mac/xamarin.iOS
* Flatten the list to get rid of the braces
* Add in keychain password
* Add login.keychain back in to access codesigning certificates
* Always sign pkgs, upload notarized copies
* Enable ios notarization and make notarized pkgs public
* Make notarization non-fatal
* Publish GH statuses for notarized PKGs
* Don't forget to declare URI variables for notarized pkgs
* report proper package links
* [jenkins] Improve package reporting.
* Use dummy function name which our tests won't complain about.
* Build native code with -std=c++14.
Apple's headers now require -std=c++14 to compile their headers in C++ mode.
This fixes a compile error that would occur with the PhotosUI framework when
compiling code for C++.
* [mmp] Use -std=c++14 when compiling.
* Fix command line output.
* [mmp] Add all source files at the end, so they all get the -x clang argument applied.
* Limit when using c++14 in mtouch according to language.
It's now required to cast objc_msgSend[Super] to a function of the correct
signature, so let's do that.
Also remove the define that allowed us to use the previous behavior.
Also limit the output from the native compiler, so that we don't overload the
IDEs with output if the native compiler produces tens of thousands of errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/6526.
New framework - but it includes some of iOS API that were previously in
QuickLook.framework. Types were moved but remains in the old namespace
until `XAMCORE_4_0` is defined.
* [WatchKit] Remove this framework for iOS while keeping backwards compatibility. Fixes#6492.
* Copy all generated sources and modify them to throw PlatformNotSupported exceptions.
* Adjust some existing source code to also throw PlatformNotSupported exceptions.
* Sprinkle Obsolete attributes generously.
* Stop generating code for the WatchKit framework for iOS.
Fixes https://github.com/xamarin/xamarin-macios/issues/6492.
* [introspection] Adjust test.
* [mtouch] Don't link with WatchKit, and show a warning if we detect code that want to use WatchKit.
* [xtro] Remove WatchKit for iOS.
* [introspection] Don't check obsoleted NSString fields for null.
There's probably a reason the field was obsoleted.
* [introspection] Add exception for the WatchKit framework.
* [xtro] Ignore obsolete enums.
There's probably a reason they're obsoleted.
In particular it solves a confusion between WKWebKit.WKErrorCode and
WatchKit.WKErrorCode: for iOS, the latter is obsoleted, and this way we always
process the former instead.
* [mtouch] Adjust wording for MT4178 to be more accurate.
* [WatchKit] Make more API obsolete/hidden.
Two classes managed to slip past the first time.
* [tests] Adjust test after WatchKit removal.
Moved some code from uikit.cs since the type moved a while ago. That
ease code sharing with macOS (XM) but it stays into the UIKit namespace
(for XI) until `XAMCORE_4_0` to ensure binary compatibility.
* [linker] Always preserve INativeObject (interface) on types. Fixes#6711
Recent versions of the linker can remove _unused_ interfaces from types.
This optimization is only done when the type is not instantiated. However
our tools and runtime requires knowing if a type represent a native
object, using `INativeObject` even if the code that creates such instance
is not marked.
In details... the issue happens because the static registrar must be able
to detect that `MTAudioProcessingTap` is a native object, so it checks
if it implements `INativeObject`. Since it does not it fails with a 4104
error.
Why does it not ? because it's handled specially by the generator and
uses `FromHandle` to lookup (not create) instance. So the linker is able
to remove the creation code (totally fine) and then remove the
`INativeObject` (not fine since we need this).
The solution is to tell (a small like to) the linker that any marked type
that implements `INativeObject` is instantiated. That way we ensure that
the tooling (run against the linked app) and the runtime can determine
those types as native.
reference: https://github.com/xamarin/xamarin-macios/issues/6711
* Move code (to a better location) to avoid collection/exception changes. Also add an unit test
* Exclude new test case from watchOS since it does not ship with MediaToolbox
Recent versions of the linker can remove _unused_ interfaces from types.
This optimization is only done when the type is not instantiated. However
our tools and runtime requires knowing if a type represent a native
object, using `INativeObject` even if the code that creates such instance
is not marked.
In details... the issue happens because the static registrar must be able
to detect that `MTAudioProcessingTap` is a native object, so it checks
if it implements `INativeObject`. Since it does not it fails with a 4104
error.
Why does it not ? because it's handled specially by the generator and
uses `FromHandle` to lookup (not create) instance. So the linker is able
to remove the creation code (totally fine) and then remove the
`INativeObject` (not fine since we need this).
The solution is to tell (a small like to) the linker that any marked type
that implements `INativeObject` is instantiated. That way we ensure that
the tooling (run against the linked app) and the runtime can determine
those types as native.
reference: https://github.com/xamarin/xamarin-macios/issues/6711
* Use the commonly used casing for `MSBuildSDKsPath` property
Handle "incorrectly" cased msbuild property names
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
* [mtouch] Whitelist new Brotli native symbols in Xamarin.Tests.Misc.PublicSymbols test
* [mtouch] Better assert in NoLLVMFailuresInWatchOS() test
We'd list the "LLVM failed" messages before even though the AOT might've crashed and the list is meaningless. Assert the exit code before that.
* [mtouch] Use new LLVM even for 32bit targets
See https://github.com/mono/mono/issues/14841 and https://github.com/mono/mono/issues/9621
* [mtouch] Work around slow LLVM in "don't link" test
See https://github.com/mono/mono/issues/14843
* Remove useless conditional
* Remove LLVM36 from Makefile
* [watch4] set right min version for arm64_32 based watch devices (#6307)
Fixes the confusion around `libmono-native*` (see for example ce5ba1e41d (commitcomment-33834491) ) when building with `MONO_BUILD_FROM_SOURCE=1`.
* reflect watchos64_32_version_min change from mono sdk
* Move mono hash info to mk/mono.mk so that existing scripts work.
* Add Makefile dependency on mono.mk where necessary
With 3e7bc29ade the Mono hash was moved from Make.config to mono.mk.
We need to add a Makefile dependency on this file wherever Make.config was used to track a Mono dependency.
* [tests] Copy mk/mono.mk to the XM test package.
* [tests] Update minOS version test after consolidating min watchOS versions everywhere.
Fixes this mtouch and mmptest failure:
1) Failed : Xamarin.Tests.ProductTests.MinOSVersion(watchOS,MinwatchOS,WatchOSSimulator,False)
Failures
Expected: <empty>
But was: < "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (mono-runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-generated-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (shared-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-invoke-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (xamarin-support-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (nsstring-localization-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-varargs-debug.arm64_32.o)."... >
* [mmp] Fix make clean target
It needs an -r to remove directories:
```
rm: bin: is a directory
rm: obj: is a directory
```
* Add new xamarin_timezone_get_local_name() to a few more places
This includes:
* 32-bit version of Xamarin.Mac.dll and OpenTK.dll
* XamMac.dll and XamMac.CFNetwork.dll
* 32-bit versions of the runtime libraries (libxammac.a and friends).
* 32-bit version of the partial static library for Xamarin.Mac.
* Classic support in the generator.
We still ship a few Classic files so that Visual Studio for Mac continue to detect that Xamarin.Mac is installed (otherwise VSfM won't open Classic projects, which makes it impossible to use the migration wizard).
This makes our build slightly faster.
Partial fix for #6300.
* [tests] Don't use unsupported characters in matrix names for yml scripts. Fixesxamarin/maccore#1831.
Matrix names must be alphanumeric (+underscore), and recently Azure DevOps
stopped working correctly if that wasn't the case (unfortunately without a
good error message though, so it took a while to figure it out).
Fixes https://github.com/xamarin/maccore/issues/1831.
* [jenkins] Fix lookup of environment variables from matrix jobs.
* [tests] Don't use unsupported characters in matrix names for yml scripts. Fixesxamarin/maccore#1831.
Matrix names must be alphanumeric (+underscore), and recently Azure DevOps
stopped working correctly if that wasn't the case (unfortunately without a
good error message though, so it took a while to figure it out).
Fixes https://github.com/xamarin/maccore/issues/1831.
* [jenkins] Fix lookup of environment variables from matrix jobs.
Add a separate provisioning script to install Xcode if it's not already installed on the bot.
For some unknown reason it needs to be a separate script, otherwise the provisionator will complain it doesn't know the required GitHub token to download Xcode.
Fixes https://github.com/xamarin/xamarin-macios/issues/6326.
* adding Speech
* Style changes and fixed copyright
* fixing requested changes
* adding spacing to make less red in diff
* adding [DisableDefaultCtor] to SFSpeechRecognitionResult and SFTranscription
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
* Update src/speech.cs
Co-Authored-By: Alex Soto <alex@alexsoto.me>
Context: 4ecedac733/src/Shared/BuildEnvironmentHelper.cs (L567-L586)
Context: 1d71d99837/tools/xabuild
When using `xibuild` to build an SDK-style project:
tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj /restore
It was failing with:
Resolving SDK 'Microsoft.NET.Sdk'...
Project "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj" is building "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj" (GetTargetFrameworks target(s)):
Building with tools version "Current".
msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Looking at this code, it looks pretty familiar -- it came from xabuild!
xibuild was currently setting `MSBuildSDKsPath` via a config file:
<msbuildToolsets default="Current">
<toolset toolsVersion="Current">
<property name="MSBuildSDKsPath" value="/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/Current/bin/Sdks" />
Reviewing the source code for MSBuild, they don't even look for this
value via MSBuild properties... They just look for Visual Studio
directories and a `MSBuildSDKsPath` environment variable. We don't have
to use this in Xamarin.Android, because we do things a different way.
There was craziness involved to get both Windows & Mac working.
For this to work on Mac, we can just set `MSBuildSDKsPath` when
starting the new MSBuild process.
I cleaned up how `MSBUILD_EXE_PATH` is set so both of these variables
are just set via `ProcessStartInfo.EnvironmentVariables`.
Now I can fully build a Xamarin.Forms project that references a
netstandard library with `xibuild`:
$ tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj /restore
...
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:15.83
~~ New Tests ~~
I went ahead and added a new Xamarin.Forms project to test and verify
that it builds. It is the Blank Forms app template from latest VS4Mac.
With the changes to `xibuild`, I was able to build with the in-process
MSBuild APIs.