xamarin
/
xamarin-macios
зеркало из
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
xamarin-macios/dotnet/targets/Xamarin.Shared.Sdk.props

125 строки
8.9 KiB
Plaintext
Исходник Обычный вид История

[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Version information -->
[dotnet] Templateify some build logic. (#10618) * [dotnet-linker] Templateify the install logic. * [builds] Templateify the Versions.plist install logic. * [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform. Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions. * [dotnet] Templateify some build code.
2021-02-11 22:17:12 +03:00
<Import Project="Microsoft.$(_PlatformName).Sdk.Versions.props" />
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<!-- This contains the OS versions we support for target platform -->
<Import Project="Microsoft.$(_PlatformName).Sdk.SupportedTargetPlatforms.props" />
<Import Project="Xamarin.Shared.Sdk.TargetFrameworkInference.props" />
Imports the .user.env file if exists and the build is from VS (#17466) This will allow the latest runtime identifier values to be evaluated in time during the MSBuild property evaluation phase. Related and dependent of this PR: https://github.com/xamarin/XamarinVS/pull/13606
2023-02-08 11:37:39 +03:00
<!-- Imports the .user.env file if exists and the build is from VS -->
<Import Project="$(MSBuildProjectFullPath).user.env" Condition="Exists('$(MSBuildProjectFullPath).user.env') And '$(BuildingInsideVisualStudio)' == 'true'" />
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<PropertyGroup>
[msbuild] Rename $(_UsingXamarinSdk) to $(UsingAppleNETSdk) (#11270) The `$(_UsingXamarinSdk)` property has been renamed to help improve external usability. This change increases parity with the Android SDK, which currently defines `$(UsingAndroidNETSdk)` for internal and external use.
2021-04-22 04:32:33 +03:00
<!-- Set to true when using the Microsoft.<platform>.Sdk NuGet. This is used by pre-existing/shared targets to tweak behavior depending on build system -->
<UsingAppleNETSdk>true</UsingAppleNETSdk>
[net6] Fixes build issues from VS for Preview 7 (#12281) * [net6] Adds missing custom linker steps when building from Windows To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`. When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS. * [net6] Updates .NET SDK path for remote tasks execution This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist. * Adds missing spaces to TaskRunner.cs
2021-07-29 16:20:20 +03:00
<!-- This is the location of the Microsoft.<platform>.Sdk NuGet (/usr/local/share/dotnet/sdk/<version>/Sdks/Microsoft.[iOS/tvOS/watchOS/macOS].Sdk) on the platform the build is running from (Mac or Win) -->
[build] Create Microsoft.iOS.Windows.Sdk workload pack (#11251) Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper [workload SDK pack][0]. The entry point for this pack has been changed, and it is now imported through the `WorkloadManifest.targets` file included in `Microsoft.NET.Workload.iOS`, rather than being imported directly from `Microsoft.iOS.Sdk`. Import ordering has otherwise changed slightly. The following files are now imported before the majority of the `Microsoft.iOS.Sdk` (and the majority of the .NET SDK targets): * Xamarin.iOS.Common.Before.props * Xamarin.iOS.Common.Before.targets After this the majority of the .NET SDK targets will load, followed by the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the `<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of: * Microsoft.iOS.Windows.Sdk.targets * tools/msbuild/* [0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-04-27 08:44:51 +03:00
<_XamarinSdkRootDirectory>$([MSBuild]::NormalizePath('$(MSBuildThisFileDirectory)', '..'))\</_XamarinSdkRootDirectory>
[net6] Fixes build issues from VS for Preview 7 (#12281) * [net6] Adds missing custom linker steps when building from Windows To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`. When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS. * [net6] Updates .NET SDK path for remote tasks execution This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist. * Adds missing spaces to TaskRunner.cs
2021-07-29 16:20:20 +03:00
<!-- This is the location of the Microsoft.<platform>.Sdk NuGet on macOS, this value will be overriden from Windows -->
<_XamarinSdkRootDirectoryOnMac>$(_XamarinSdkRootDirectory)</_XamarinSdkRootDirectoryOnMac>
[build] Create Microsoft.iOS.Windows.Sdk workload pack (#11251) Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper [workload SDK pack][0]. The entry point for this pack has been changed, and it is now imported through the `WorkloadManifest.targets` file included in `Microsoft.NET.Workload.iOS`, rather than being imported directly from `Microsoft.iOS.Sdk`. Import ordering has otherwise changed slightly. The following files are now imported before the majority of the `Microsoft.iOS.Sdk` (and the majority of the .NET SDK targets): * Xamarin.iOS.Common.Before.props * Xamarin.iOS.Common.Before.targets After this the majority of the .NET SDK targets will load, followed by the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the `<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of: * Microsoft.iOS.Windows.Sdk.targets * tools/msbuild/* [0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-04-27 08:44:51 +03:00
<_XamarinTaskAssembly Condition="'$(_PlatformName)' != 'macOS'">$(_XamarinSdkRootDirectory)\tools\msbuild\iOS\Xamarin.iOS.Tasks.dll</_XamarinTaskAssembly>
<_XamarinTaskAssembly Condition="'$(_PlatformName)' == 'macOS'">$(_XamarinSdkRootDirectory)\tools\msbuild\macOS\Xamarin.Mac.Tasks.dll</_XamarinTaskAssembly>
[dotnet] suppress IL2026 linker warning (#11043) We started using `$(SuppressTrimAnalysisWarnings)` by default, because ILLink started emitting warnings by default in .NET 6 Preview 3. 7bf3e8d8 fixed *most* of these warnings except for `IL2026`: https://github.com/dotnet/sdk/blob/16aedd6e72bd2f8dea01918478fc1368bc017fe9/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L52-L57 I get around 20 instances of this warning when building dotnet/maui. `IL2026` occurs because this logic is evaluated much earlier than the `PrepareForILLink` MSBuild target: https://github.com/dotnet/sdk/blob/16aedd6e72bd2f8dea01918478fc1368bc017fe9/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L202 The MSBuild evaluation order right now is: * Sdk/Sdk.props * Microsoft.[platform].Sdk.props * Xamarin.Shared.Sdk.props * Microsoft.NET.ILLink.targets * Microsoft.[platform].Sdk.targets * Xamarin.Shared.Sdk.targets We need to set `$(SuppressTrimAnalysisWarnings)` earlier in `Xamarin.Shared.Sdk.props` to solve the issue here. On the Android side I got lucky, and it worked first try without thinking too much. We import a `*.DefaultProperties.targets` before `Microsoft.NET.ILLink.targets`, and that is why it worked.
2021-03-31 17:07:02 +03:00
<SuppressTrimAnalysisWarnings Condition=" '$(SuppressTrimAnalysisWarnings)' == '' ">true</SuppressTrimAnalysisWarnings>
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
<AfterMicrosoftNETSdkTargets>$(AfterMicrosoftNETSdkTargets);$(MSBuildThisFileDirectory)Microsoft.$(_PlatformName).Sdk.targets</AfterMicrosoftNETSdkTargets>
[msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes #10827. (#11433) * [dotnet] Ship the buildinfo file. * [msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes #10827. We do this by setting the _XamarinSdkRoot variable in our .NET logic, which our existing shared build logic reads, passes to the DetectSdkLocations task, and then sets our override environment variable (MD_MTOUCH_SDK_ROOT/XAMMAC_FRAMEWORK_PATH) to the install location, so that existing code (which honors the override variable) continues to work as-is. Fixes https://github.com/xamarin/xamarin-macios/issues/10827.
2021-05-05 04:36:48 +03:00
<!-- _XamarinSdkRoot is used by the existing MSBuild targets files -->
<_XamarinSdkRoot Condition="'$(_XamarinSdkRoot)' == ''">$(_XamarinSdkRootDirectory)</_XamarinSdkRoot>
[dotnet] Fix _DetectSdkLocations from Windows (#11451) This task ends up setting as env variable the Xamarin Sdk root directory on the Mac, but when building from Windows it was setting the Windows path, so instead we need to override it with the proper value on macOS. This should not change the original behavior when building from macOS.
2021-05-06 08:42:43 +03:00
<!-- _XamarinSdkRootOnMac this should be passed to tasks that need to access the Xamarin Sdk dir on the Mac, this value will be overriden from Windows -->
<_XamarinSdkRootOnMac>$(_XamarinSdkRoot)</_XamarinSdkRootOnMac>
[dotnet] Tell .NET to not generate files we don't need. Fixes #9687. (#11693) Tell .NET to not generate files we don't need: * Dependency file (*.deps.json). * Reference assemblies for executable projects. Fixes https://github.com/xamarin/xamarin-macios/issues/9687.
2021-05-31 19:06:42 +03:00
<!-- We don't need any dependency files -->
<GenerateDependencyFile Condition="'$(GenerateDependencyFile)' == ''">false</GenerateDependencyFile>
[dotnet] Make sure that MSBuild doesn't strip away our PublishFolderType metadata
2021-08-12 13:30:57 +03:00
<!-- MSBuild will discard the 'PublishFolderType' metadata on items unless we set these properties -->
<MSBuildDisableGetCopyToOutputDirectoryItemsOptimization>true</MSBuildDisableGetCopyToOutputDirectoryItemsOptimization>
<MSBuildDisableGetCopyToPublishDirectoryItemsOptimization>true</MSBuildDisableGetCopyToPublishDirectoryItemsOptimization>
[dotnet] Only validate the RuntimeIdentifier if we need/use it. Fixes #13482. (#14339) Fixes https://github.com/xamarin/xamarin-macios/issues/13482.
2022-03-09 10:22:52 +03:00
<!-- Do we need a RuntimeIdentifier? For apps and app extensions we do -->
<_RuntimeIdentifierIsRequired Condition="'$(OutputType)' == 'Exe' Or '$(IsAppExtension)' == 'true'">true</_RuntimeIdentifierIsRequired>
[dotnet] Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore. Fixes #16193. (#16306) Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore, because .NET gets it wrong when building from inside VS (Windows). When building using either VSMac or the command line (either from Windows or Mac), the `MSBuildRuntimeType` property is set to `Core`, and as a result, the default value for `GenerateSatelliteAssembliesForCore` is `true`: ```xml <GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore> ``` See: https://github.com/dotnet/sdk/blob/00100960bf06cb595daba647673cd0329be896f4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets#L41 This is the correct behavior. However, when building from inside Visual Studio (for Windows), the `MSBuildRuntimeType` property is set to `Full`, and thus `GenerateSatelliteAssembliesForCore` is not set to `true`, and we end up executing al.exe to generate satellite assemblies, which is wrong (al.exe complains that 'arm64' is an invalid platform). Fix this by always defaulting `GenerateSatelliteAssembliesForCore` to `true`, independent on where we're executing. Ref: https://github.com/dotnet/sdk/issues/28419. Fixes https://github.com/xamarin/xamarin-macios/issues/16193.
2022-10-10 22:41:36 +03:00
<!-- The logic to compute the default value for GenerateSatelliteAssembliesForCore is wrong when building inside Visual Studio (Windows), so make sure it defaults to the correct value -->
<!-- Ref: https://github.com/xamarin/xamarin-macios/issues/16193 -->
<!-- Ref: https://github.com/dotnet/sdk/issues/28419 -->
<GenerateSatelliteAssembliesForCore Condition="'$(GenerateSatelliteAssembliesForCore)' == ''">true</GenerateSatelliteAssembliesForCore>
[dotnet] Ensure any trimmer components are restored properly. (#17227) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM).
2023-01-16 10:21:09 +03:00
<!-- This will ensure any trimmer components are restored by the framework reference logic. As such it must happen before Microsoft.NET.Publish.targets is included.
Ref:
* https://github.com/dotnet/sdk/pull/29441
* https://github.com/dotnet/sdk/blob/c5a58bc6c3eb2b236b314e6d17a89a537459890c/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Publish.targets#L20-L21
* https://github.com/dotnet/sdk/blob/c5a58bc6c3eb2b236b314e6d17a89a537459890c/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets#L102
-->
<_IsTrimmingEnabled>true</_IsTrimmingEnabled>
[dotnet] Enable generation of runtime configuration file (#17840) Set the GenerateRuntimeConfigurationFiles (GRCF) property to true to avoid warnings at build time + add test for change. Diving deeper into the fix... - This warning only occurs with .NET apps which is why GRCF is only updated in the dotnet directory and not msbuild (legacy) - After examining the binlog (see issue), it was found that the GRCF was contingent upon the HasRuntimeOutput property, which is only defined for executable projects. And in this case, the user's project output type is library thus both the RuntimeOutput and consequently GRCF properties were not enabled. - By setting the GRCF to true we can address the original warning of concern while ensuring the rest of the projects's behavior is not altered in mysterious ways (i.e. by touching the RuntimeOutput property or the project output type instead, these changes could have extraneous effects). Fixes #17543 --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2023-03-23 18:10:04 +03:00
<!-- The GRCF property is contingent upon the HasRuntimeOutput property, which is only defined for executable projects. So, explicitly define GRCF for extension projects to avoid warnings at build time. -->
<GenerateRuntimeConfigurationFiles Condition="'$(IsAppExtension)' == 'true'">true</GenerateRuntimeConfigurationFiles>
[dotnet] Set _RequiresILLinkPack=true so that we always restore the ILLink package. (#18412) This property will be required when building for a net7.0-* target framework using .NET 8 (preview 6 - preview 5 does not need this fix) Backport of #18411
2023-06-07 09:48:42 +03:00
<!-- Setting _RequiresILLinkPack to true so that the ILLink pack is always restored. -->
<_RequiresILLinkPack Condition="'$(_RequiresILLinkPack)' == ''">true</_RequiresILLinkPack>
Reduce the size of `__LINKEDIT Export Info` section in stripped binaries (#18408) # Description This PR reduces the application's SOD (size on disk) by making `__LINKEDIT Export Info` section smaller in the stripped Mach-O binaries. The feature is controlled by `_ExportSymbolsExplicitly` MSBuild property and can be disabled by specifying: `-p:_ExportSymbolsExplicitly=true` Fixes #18332 # Initial problem It has been noticed that during stripping, the strip tool does not resize the export info section after it removes the symbols. Instead it only zeroes out the entries (achieved by calling `prune_trie` function): - https://github.com/apple-oss-distributions/cctools/blob/cctools-986/misc/strip.c - https://github.com/apple-oss-distributions/ld64/blob/ld64-711/src/other/PruneTrie.cpp Thanks @lambdageek for helping to track this down. # Approach As Xamarin build process already collects all the [required symbols][1] needed for the application to run and preserves them during the strip phase, we can use the same file to instruct clang toolchain to export only those symbols via the command line options: `-exported_symbols_list <file>` ([source][2]). This will make the export info section only include what is necessary for the runtime - and at the same time eliminate the problem of the `strip` tool which does not resize stripped symbols. # Investigation setup The issue is observable by building and inspecting the test application: https://github.com/xamarin/xamarin-macios/blob/main/tests/dotnet/MySingleView/MySingleView.csproj and targeting iOS platform in Release mode. ## Results: | Measure | MySingleView - main | MySingleView - this PR | Diff (%) | | :--- | ---: | ---: | ---: | | SOD (bytes) | 13668940 | 13458476 | -1.5% | | .ipa (bytes) | 4829368 | 4827928 | -0.03% | Even though zeroes are compressed well, the SOD is still affected and unused section takes around 1.5% of the most simplistic app size. Much bigger impact has been noted when trying out a MAUI iOS template app with NativeAOT where the `__LINKEDIT Export Info` zeroes take up to 20MB of the SOD, but also with the regular macOS applications: https://github.com/dotnet/runtime/issues/86707 ### Repro current state of MySingleView.app with stripped binary 1. Build the app (you can ignore the need to run the sample, I just did it to make sure the changes do not break anything) ```bash make run-device ``` 2. Print the load commands - [load_cmds_strip.list][3] ```bash otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_strip.list ``` - We are interested in the export info section: ``` cmd LC_DYLD_INFO_ONLY ... export_off 5942960 export_size 207712 ``` 3. Create a hex dump of the export info section - [hex_dump_strip.list][4] ``` bash xxd -s 5942960 -l 207712 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_strip.list ``` - NOTE: Notice around ~200kb of zeroes from ~0x005ab490 to ~0x005dda00 4. Verify exported symbols are correct - [dyld_info_strip.list][5] ``` bash dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_strip.list ``` ### Repro current state of MySingleView.app with unstripped binary 1. Build the app (the make target preserves the symbols) ```bash make run-device-no-strip ``` 2. Print the load commands - [load_cmds_nostrip.list][6] ```bash otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_nostrip.list ``` - We are interested in the export info section: ``` cmd LC_DYLD_INFO_ONLY ... export_off 5942960 export_size 207712 ``` 3. Create a hex dump of the export info section - [hex_dump_nostrip.list][7] ``` bash xxd -s 5942960 -l 207712 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_nostrip.list ``` - Notice that the range: ~ 0x005ab490 to ~ 0x005dda00 now includes exported symbol entries 4. Verify exported symbols are correct - [dyld_info_nostrip.list][8] ``` bash dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_nostrip.list ``` ### Repro the new approach 1. Build the app (the make target uses the new approach) ```bash make run-device-export-syms ``` 2. Print the load commands - [load_cmds_export.list][9] ```bash otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_export.list ``` - We are interested in the export info section ***notice the reduced size of the section***: ``` cmd LC_DYLD_INFO_ONLY ... export_off 5942432 export_size 1048 ``` 3. Create a hex dump of the export info section - [hex_dump_export.list][10] ``` bash xxd -s 5942432 -l 1048 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_export.list ``` 4. Verify exported symbols are correct - [dyld_info_export.list][11] ``` bash dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_export.list ``` --- ## Additional benefits With this approach we could also switch the way strip tool is invoked to always strip all debug and local symbols via `strip -S -x` instead of passing the file with symbols to preserve. This would remove the warning that we are currently getting (which is being ignored): ``` /Applications/Xcode_14.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: warning: removing global symbols from a final linked no longer supported. Use -exported_symbols_list at link time when building... ``` ## Other references: - https://github.com/qyang-nj/llios/blob/main/exported_symbol/README.md [1]: https://github.com/xamarin/xamarin-macios/blob/11e7883da04d80c59e4ffbbc955a3e0e0060ff90/tools/dotnet-linker/Steps/GenerateReferencesStep.cs#L38-L44 [2]: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html [3]: https://gist.github.com/ivanpovazan/d53f8d10be5e4ea9f39a41ea540aa7fa [4]: https://gist.github.com/ivanpovazan/60637422f3ff8cb5f437ddd06a21d9c1 [5]: https://gist.github.com/ivanpovazan/352595ad15c2ac02f38dcb3bd4130642 [6]: https://gist.github.com/ivanpovazan/bf700161f2f3691d1d7381c98d4fa0be [7]: https://gist.github.com/ivanpovazan/44269e4fff5ebd58a4d181451e5c106f [8]: https://gist.github.com/ivanpovazan/38c5afe076502d514a77420af0e10b01 [9]: https://gist.github.com/ivanpovazan/3f663c3c630005f5a578605d48ba807e [10]: https://gist.github.com/ivanpovazan/0bb84f64281d05ab20438aeaed64f13c [11]: https://gist.github.com/ivanpovazan/78b3ba2288f53a2316b9bc46964e7e4f --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2023-06-12 14:45:38 +03:00
<!-- Explicitly export symbols using clang command-line option "-exported_symbols_list export_list" -->
<_ExportSymbolsExplicitly Condition="'$(_ExportSymbolsExplicitly)' == ''">true</_ExportSymbolsExplicitly>
[dotnet] Set AutoreleasePoolSupport earlier so that the linker doesn't set it first. Might not be necessary: https://github.com/dotnet/runtime/pull/86753
2023-06-21 21:49:52 +03:00
<!--
Some runtime libraries feature switches defaults that need to be set early
Available feature switches: https://github.com/dotnet/runtime/blob/master/docs/workflow/trimming/feature-switches.md
-->
<!-- AutoreleasePoolSupport needs to be set earlier than other switches, so that illink doesn't override it - https://github.com/dotnet/runtime/pull/86753 - so it's set here, instead of in Xamarin.Shared.Sdk.targets -->
<AutoreleasePoolSupport Condition="'$(AutoreleasePoolSupport)' == ''">true</AutoreleasePoolSupport>
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
</PropertyGroup>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
<!-- Set the default RuntimeIdentifier if not already specified. -->
[dotnet] Only validate the RuntimeIdentifier if we need/use it. Fixes #13482. (#14339) Fixes https://github.com/xamarin/xamarin-macios/issues/13482.
2022-03-09 10:22:52 +03:00
<PropertyGroup Condition="'$(_RuntimeIdentifierIsRequired)' == 'true' And '$(RuntimeIdentifier)' == '' And '$(RuntimeIdentifiers)' == '' ">
[dotnet] Make relase builds for desktop universal by default. Fixes #15620. (#15769)
2022-08-31 17:45:10 +03:00
<!-- The _<platform>RuntimeIdentifier values are set from the IDE -->
[dotnet] Adds platform specific RID options (#14643) This enables Visual Studio to set a specific `RuntimeIdentifier` for each platform when building all target frameworks in a MAUI project. Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2022-04-06 10:39:33 +03:00
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'iOS'">$(_iOSRuntimeIdentifier)</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'tvOS'">$(_tvOSRuntimeIdentifier)</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'macOS'">$(_macOSRuntimeIdentifier)</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(_PlatformName)' == 'MacCatalyst'">$(_MacCatalystRuntimeIdentifier)</RuntimeIdentifier>
<_XamarinUsingDefaultRuntimeIdentifier Condition="'$(RuntimeIdentifier)' == ''">true</_XamarinUsingDefaultRuntimeIdentifier>
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(_PlatformName)' == 'iOS'">iossimulator-x64</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(_PlatformName)' == 'tvOS'">tvossimulator-x64</RuntimeIdentifier>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
[dotnet] Make relase builds for desktop universal by default. Fixes #15620. (#15769)
2022-08-31 17:45:10 +03:00
<!-- For release desktop builds we default to universal apps in .NET 7+ -->
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' != 'Release' And '$(_PlatformName)' == 'macOS'">osx-x64</RuntimeIdentifier>
<RuntimeIdentifier Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' != 'Release' And '$(_PlatformName)' == 'MacCatalyst'">maccatalyst-x64</RuntimeIdentifier>
<RuntimeIdentifiers Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' == 'Release' And '$(_PlatformName)' == 'macOS'">osx-x64;osx-arm64</RuntimeIdentifiers>
<RuntimeIdentifiers Condition="'$(RuntimeIdentifier)' == '' And '$(Configuration)' == 'Release' And '$(_PlatformName)' == 'MacCatalyst'">maccatalyst-x64;maccatalyst-arm64</RuntimeIdentifiers>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
[dotnet] Always set 'UseAppHost' and '_RuntimeIdentifierUsesAppHost' to 'false' in .NET. Otherwise .NET might want to include an app host in the app, which ends up with a build warning, because we don't use apphosts.
2021-12-17 01:15:09 +03:00
</PropertyGroup>
<!-- We're never using any app hosts -->
<PropertyGroup>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
<_RuntimeIdentifierUsesAppHost>false</_RuntimeIdentifierUsesAppHost>
<UseAppHost>false</UseAppHost>
</PropertyGroup>
[dotnet] Enable LLVM by default for release builds. Fixes #12147. (#12660) Fixes https://github.com/xamarin/xamarin-macios/issues/12147.
2021-09-08 19:04:39 +03:00
[net8.0] Update dependencies from dotnet/installer (#18271) This pull request updates the following dependencies ## Coherency Updates The following updates ensure that dependencies with a *CoherentParentDependency* attribute were produced in a build used as input to the parent dependency's build. See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview) - **Coherency Updates**: - **Microsoft.NET.ILLink.Tasks**: from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3 (parent: Microsoft.Dotnet.Sdk.Internal) - **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.5.23252.26 to 8.0.0-preview.5.23262.1 (parent: Microsoft.Dotnet.Sdk.Internal) - **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3 (parent: Microsoft.Dotnet.Sdk.Internal) - **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: from 8.0.0-preview.5.23225.2 to 8.0.0-preview.5.23252.1 (parent: Microsoft.NETCore.App.Ref) - **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3 (parent: Microsoft.Dotnet.Sdk.Internal) ## From https://github.com/dotnet/installer - **Subscription**: f9b68d84-9c90-4bd0-5499-08db4112d57e - **Build**: 20230517.7 - **Date Produced**: May 17, 2023 9:29:46 PM UTC - **Commit**: dda516cbd77ab9dc3c6048a1893b4321cdcda195 - **Branch**: refs/heads/main - **Updates**: - **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.5.23258.8 to 8.0.100-preview.5.23267.7][29] - **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3][30] - **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.5.23252.26 to 8.0.0-preview.5.23262.1][31] - **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3][30] - **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: [from 8.0.0-preview.5.23225.2 to 8.0.0-preview.5.23252.1][32] - **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3][30] [29]: https://github.com/dotnet/installer/compare/1ab664ce1c...dda516cbd7 [30]: https://github.com/dotnet/runtime/compare/bc9dad2351...888bac3044 [31]: https://github.com/dotnet/aspnetcore/compare/730dac21a5...059939bda4 [32]: https://github.com/dotnet/emsdk/compare/81590b9b84...ab09b0b8d6
2023-05-19 08:33:48 +03:00
<!-- If a runtime identifier is required, and we have a runtime identifier, then we must be self contained.
This of course begs the question: when could we have a runtime identifier and such a thing would not be required?
The answer is: library projects may end up with a RuntimeIdentifier when building a referencing executable project
from the command line, and that command line specifies a RuntimeIdentifier -->
<PropertyGroup Condition="'$(_RuntimeIdentifierIsRequired)' == 'true' And '$(RuntimeIdentifier)' != ''">
[net6][msbuild] Set SelfContained for AppExtensions sooner to fix publishing (#12703) This PR resolves a crash when running the linker on publishing iOS extensions. The crash would occur here in failing to resolve corelib. The reason this would fail was System.Private.CoreLib.dll was not in input_assemblies. This was because we were passes the set of reference assemblies not the expected 'real' ones, and those do not include CoreLib. After a bunch of digging, this was because _ComputeManagedRuntimePackAssembliesIfSelfContained target was not being set as a condition of _ComputeAssembliesToPostprocessOnPublish. _ComputeManagedRuntimePackAssembliesIfSelfContained happened to be the place these were added, and wasn't being set since it has a condition of $(SelfContained) == 'true' Now confusingly SelfContained WAS being set to true, but only in the targets file, which was too late, as it was checked in a 'global' property group outside of a target. This means we'd fail to set SelfContained until after the condition, and not run. This was verified by setting /p:SelfContained=true to true. I also looked at removing the condition above, since https://github.com/dotnet/runtime/issues/54406 is fixed, however this caused project that didn't set RuntimeIdentifier to fail.
2021-09-20 17:40:41 +03:00
<SelfContained>true</SelfContained>
</PropertyGroup>
[dotnet] Enable LLVM by default for release builds. Fixes #12147. (#12660) Fixes https://github.com/xamarin/xamarin-macios/issues/12147.
2021-09-08 19:04:39 +03:00
<!--
Enable LLVM by default for mobile release builds.
At this point we don't necessarily know yet whether we're building for device or simulator,
but the MtouchUseLlvm value is ignored when using the simulator, so it doesn't matter
if we set it in all cases.
-->
<PropertyGroup Condition="'$(MtouchUseLlvm)' == '' And '$(Configuration)' == 'Release' And ('$(_PlatformName)' == 'iOS' Or '$(_PlatformName)' == 'tvOS')">
<MtouchUseLlvm>true</MtouchUseLlvm>
[dotnet] Set the default RuntimeIdentifier earlier.
2021-06-21 13:51:20 +03:00
</PropertyGroup>
[dotnet] Disable our own IL stripping when using NativeAOT, because NativeAOT already does something equivalent
2023-06-21 21:49:54 +03:00
<!-- Various options when using NativeAOT -->
<PropertyGroup Condition="'$(PublishAot)' == 'true'">
<!-- Disable our own assembly IL stripping logic, because ILC does that already -->
<EnableAssemblyILStripping>false</EnableAssemblyILStripping>
<!-- We're using our own native main function when using NativeAOT -->
<CustomNativeMain>true</CustomNativeMain>
</PropertyGroup>
[dotnet] Reorder imports to account for that our targets are imported earlier in the build process. In the latest .NET 6, our Workloads.targets is imported earlier in the build. This requires a few changes, because we still need to run most of our logic later in the process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets property. What we're loading as soon as possible: * Our version information (Xamarin.Shared.Sdk.Versions.targets) * The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets) * The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets). This is all information that the .NET build require early on. Changes: * Rename all files that are loaded early to *.props. * Updated documentations to reflect these changes. * Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't used and don't contain anything useful. * Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed to later, because it needs TargetFrameworkMoniker set.
2020-11-05 12:06:45 +03:00
</Project>