This will be required when we make blocks use blittable callbacks, since we'll
have to use pointers in a few cases (because ref/out arguments aren't
blittable).
Autotools-based project using libtool's -module flag generate plugins
with the .so extension that needs to be treated like DynamicLibraries in
terms of deployment location and relocation, except they are not linked
to the app.
This PR adds support for such .so files: they're treated as .dylib files, except
that they're not linked to the app.
Dynamic libraries might be deployed in subdirectories such as libclrjit.dylib from the nuget package cefglue.common:
Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
The library ID for that library should be: @executable_path/../MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Instead of: @executable_path/../MonoBundle/libclrjit.dylib
Beside the library ID being wrong, when it's combined with the nuget package microsoft.netcore.app.runtime.osx-x64 providing a library with the same name, both uses the same `ReidentifiedPath`, which can cause a failure in the InstallNameTool tasks that are run in parallel operating on the same temporary file.
The following patch uses the `RelativePath` for the tempory file used by `InstallNameTool` so that there are no clashes with other files with the same name deployed in other directories. It also uses the `RelativePath` to create the correct library id: @executable_path/../../Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Partially fixes https://github.com/xamarin/xamarin-macios/issues/15173 for this scenario
Fixes this:
Making all in frameworks
/bin/sh: .libs/tvos-arm64/FrameworksInRuntimesNativeDirectory1.dll: No such file or directory
make[2]: *** [.libs/tvos-arm64/FrameworksInRuntimesNativeDirectory1.dll] Error 1
Since executables in frameworks usually don't have dots, `%(Filename)` will be
the entire filename, because `%(Extension)` is empty. However, if the
executable happens to have a dot, then we need to include the extension:
`%(Filename)%(Extension)`.
Fixes https://github.com/xamarin/xamarin-macios/issues/15727.
When we changed SCNMatrix4 to be column-major instead of row-major in .NET, there
were several other related changes we should have done but didn't do. In particular
we should have made transformation operations based on column-vectors instead of
row-vectors.
In legacy Xamarin, a vector would be transformed by a transformation matrix by doing
matrix multiplication like this:
[ x y z w] * [ 11 21 31 41 ]
| 12 22 32 42 |
| 13 23 33 43 |
[ 14 24 34 41 ]
In this case the vector is a row-vector, and it's the left operand in the multiplication.
When using column-major matrices, we want to use column-vectors, where the vector
is the right operand, like this:
[ 11 21 31 41 ] * [ x ]
| 12 22 32 42 | | y |
| 13 23 33 43 | | z |
[ 14 24 34 41 ] [ w ]
This affects numerous APIs in SCNMatrix4, SCNVector3 and SCNVector4:
* The M## fields have been changed to make the first number the column and the
second number the row, to reflect that it's a column-major matrix (this is
also how it's defined in the native SCNMatrix4 type).
* Functions that return a transformation matrix have been modified to return column-vector
transformers. Technically this means that these matrices are transposed compared
to legacy Xamarin. The functions involved are:
* CreateFromAxisAngle
* CreateRotation[X|Y|Z]
* CreateTranslation
* CreatePerspectiveFieldOfView
* CreatePerspectiveOffCenter
* Rotate
* LookAt
* Combining two column-vector transforming transformation matrices is done by multiplying
them in the reverse order, so the Mult function (and the multiplication operator)
have been modified to multiply the given matrices in the opposite order (this matches
how the SCNMatrix4Mult function does it). To make things clearer I've changed the
parameter names for XAMCORE_5_0.
* Functions that transform a vector using a transformation matrix have been modified
to do a column-vector transformation instead of a row-vector transformation. This
involves the following functions:
* SCNVector3.TransformVector
* SCNVector3.TransformNormal
* SCNVector3.TransformNormalInverse
* SCNVector3.TransformPosition
* SCNVector4.Transform
* Numerous new tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/15094.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
* Make the custom-type-assembly library build using assemblies relative to
MAC_DESTDIR, instead of poking into $(TOP)/_mac-build (for legacy Xamarin).
* Build the custom-type-assembly using a project file for .NET (and use our
local .NET).
* Change the default for [IOS|MAC]_DESTDIR when TESTS_USE_SYSTEM is set to
point to the system installation.
* Make sure 'MSBuildSDKsPath' isn't set when building the custom-type-assembly
(set by xibuild), it breaks a lot of things.
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
* Use 'ObjCException' instead of 'MonoTouchException' as the managed exception
type wrapping an NSException for all platforms in .NET (that was already the
case for macOS, so no change there).
* Make the ObjCException class behave like the MonoTouchException class does.
* Move the ObjCException type to the ObjCRuntime namespace in .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/13855.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Public fields shouldn't start with a lower-cased letter.
Also provide public properties in legacy Xamarin so that we can write
identical code for both, and obsolete the lower-cased fields.
This turned out a bit complicated, because we're lipo'ing together both the simulator
and device slices, and that doesn't work anymore when ARM64 is both a simulator and
a device architecture. The solution is a custom lipo logic that doesn't include the
simulator version of the ARM64 architecture in the final binary.
* [tests] Create a libtest.xcframework and libtest2.xcframework
* [tests] Make bindings-test and bindings-test2 use an xcframework instead of plain static library
* [msbuild] Add support for xcframeworks with static libraries in them.
* List the frameworks libtest needs.
* [tests] Update .NET unit tests according to test project changes.
* [tests] Add new test to verify that packing an old-style binding project doesn't work.
This makes it easier to iterate over all the *_SDK_VERSION variables in
template code, because they're all named using the standard platform names we
use elsewhere.
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
It's a bit weird to build it twice, but it's the most straight forward way of
making the test work if either the .NET build or the legacy build is disabled.
When checking whether a type is a user type or not, we might have to do a
dynamic check if the dynamic registrar is available. Otherwise we may run into
a situation where the static registrar ran during the app build, but then the
app loaded additional assemblies at runtime, and those assemblies contained
user types that were registered using the dynamic registrar, so the static
registrar doesn't know about those custom types (in other words: we need to
check at runtime).
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support for
MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework
/ dynamic library to the app bundle).
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
* [runtime] Build our runtime for Mac Catalyst/ARM64 for .NET.
* [ObjCRuntime] There's no need for the StartWWAN implementation on Mac Catalyst.
This also fixes a build error:
error MT5214: Native linking failed, undefined symbol: _xamarin_start_wwan. This symbol was referenced by the managed member ObjCRuntime.Runtime.xamarin_start_wwan.
* Only exclude xamarin_start_wwan in the .NET version of Mac Catalyst.
* [tests] Update to not run the StartWWAN test on Mac Catalyst.
* Update conditional logic.
* Fix build with newer make versions.
* [tests] Build test-libraries for Mac Catalyst.
* [msbuild] Add support for Mac Catalyst binding projects.
* [mtouch] Allow frameworks for Mac Catalyst apps.
* [mtouch] Put frameworks in the expected location for Mac Catalyst apps.
* [msbuild] Create the Resources directory before trying to put files in it.
This is done early so we can resolve the inner framework, inside the
xcframework, and let the existing framework support do most of the
work.
The resolving code has unit tests. Custom projects for "NoEmbedding"
exists for all supported platforms and executed by xharness.
A sample `xcframework` with tests projects is also available
[here](https://github.com/spouliot/xcframework).
The xcframework test case is based on Rolf's earlier/partial implementation.
https://github.com/rolfbjarne/xamarin-macios/commit/xcframework
Things to note:
Do not rename a framework (like XTest) to use it in an xcframework
(like XCTest). That will fail at codesign but won't give anything
useful. You might think signing the framework (instead of the inner
binary) would solve it. It does, as it codesign, but then the app
crash at startup. At some point you realize some symbols are still
using XTest (not XCTest) and then you can delete several other weird
workarounds (like for `ld`) because all of it was cause by this
never identified rename.
dSYM support (and tests) to be done in a separate PR.
Rolf Bjarne Kvinge
Andoni Morales Alastruey
Alex Soto
Sebastien Pouliot