You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Opening an issue to track various patches/workarounds we do in Homebrew for macOS build to find out which are already fixed, if we need to upstream some, to discuss better ways to fix, and/or if should be part of documentation.
Build failure on macOS ARM due to osx-x64 override. The following is the patch we use to allow using osx-arm64. If acceptable, I can create PR in dotnet/installer:
Patch
diff --git a/src/SourceBuild/tarball/content/repos/installer.proj b/src/SourceBuild/tarball/content/repos/installer.proj
index 712d7cd14..31d54866c 100644
--- a/src/SourceBuild/tarball/content/repos/installer.proj+++ b/src/SourceBuild/tarball/content/repos/installer.proj@@ -7,7 +7,7 @@
<PropertyGroup>
<OverrideTargetRid>$(TargetRid)</OverrideTargetRid>
- <OverrideTargetRid Condition="'$(TargetOS)' == 'OSX'">osx-x64</OverrideTargetRid>+ <OverrideTargetRid Condition="'$(TargetOS)' == 'OSX'">osx-$(Platform)</OverrideTargetRid>
<OSNameOverride>$(OverrideTargetRid.Substring(0, $(OverrideTargetRid.IndexOf("-"))))</OSNameOverride>
<RuntimeArg>--runtime-id $(OverrideTargetRid)</RuntimeArg>
@@ -28,7 +28,7 @@
<BuildCommandArgs Condition="'$(TargetOS)' == 'Linux'">$(BuildCommandArgs) /p:AspNetCoreSharedFxInstallerRid=linux-$(Platform)</BuildCommandArgs>
<!-- core-sdk always wants to build portable on OSX and FreeBSD -->
<BuildCommandArgs Condition="'$(TargetOS)' == 'FreeBSD'">$(BuildCommandArgs) /p:CoreSetupRid=freebsd-x64 /p:PortableBuild=true</BuildCommandArgs>
- <BuildCommandArgs Condition="'$(TargetOS)' == 'OSX'">$(BuildCommandArgs) /p:CoreSetupRid=osx-x64</BuildCommandArgs>+ <BuildCommandArgs Condition="'$(TargetOS)' == 'OSX'">$(BuildCommandArgs) /p:CoreSetupRid=osx-$(Platform)</BuildCommandArgs>
<BuildCommandArgs Condition="'$(TargetOS)' == 'Linux'">$(BuildCommandArgs) /p:CoreSetupRid=$(TargetRid)</BuildCommandArgs>
<!-- Consume the source-built Core-Setup and toolset. This line must be removed to source-build CLI without source-building Core-Setup first. -->
diff --git a/src/SourceBuild/tarball/content/repos/runtime.proj b/src/SourceBuild/tarball/content/repos/runtime.proj
index f3ed143f8..2c62d6854 100644
--- a/src/SourceBuild/tarball/content/repos/runtime.proj+++ b/src/SourceBuild/tarball/content/repos/runtime.proj@@ -3,7 +3,7 @@
<PropertyGroup>
<OverrideTargetRid>$(TargetRid)</OverrideTargetRid>
- <OverrideTargetRid Condition="'$(TargetOS)' == 'OSX'">osx-x64</OverrideTargetRid>+ <OverrideTargetRid Condition="'$(TargetOS)' == 'OSX'">osx-$(Platform)</OverrideTargetRid>
<OverrideTargetRid Condition="'$(TargetOS)' == 'FreeBSD'">freebsd-x64</OverrideTargetRid>
<OverrideTargetRid Condition="'$(TargetOS)' == 'Windows_NT'">win-x64</OverrideTargetRid>
Build failure on macOS due to missing ILAsm/ILDAsm. This seems to be common issue on Linux too. The odd thing though is that RuntimeOsxArm64MicrosoftNETCoreILAsmVersion exists but RuntimeOsxX64MicrosoftNETCoreILAsmVersion doesn't, so needed to use Linux's version for x64. Not sure if this should be added, or if this is a .NET packaging issue that will be fixed. (EDIT: In 6.0.103, need to use Linux versions for osx-arm64 too) e.g.
Error MSB4018 while building 'installer in tarball' due to trying to find aspnetcore-runtime-internal v6.0.0 rather than current. Need to find out why this is happening. The hack done is change MicrosoftAspNetCoreAppRuntimePackageVersion to MicrosoftAspNetCoreAppRuntimewinx64PackageVersion inside src/installer.*/src/redist/targets/GenerateLayout.targets
EDIT 1: May not be needed anymore in 6.0.103
EDIT 2: Actual, based on Homebrew PR, still needed on osx-x64 as looking for v6.0.2
Temporary issue but need to manually remove src/nuget-client.*/eng/source-build-patches/0001-Rename-NuGet.Config*.patch since macOS is case-insensitive OS. Would be good to be able to identify patches that are platform-compatible and have source-build skip them. Otherwise, Homebrew can continue removing incompatible patches as necessary.
Opening an issue to track various patches/workarounds we do in Homebrew for macOS build to find out which are already fixed, if we need to upstream some, to discuss better ways to fix, and/or if should be part of documentation.
Some prior discussion in #2719 and 6.0.102 work in Homebrew PR Homebrew/homebrew-core#95339 (EDIT: 6.0.103 work in PR Homebrew/homebrew-core#96612)
Build failure on macOS ARM due to
osx-x64override. The following is the patch we use to allow usingosx-arm64. If acceptable, I can create PR in dotnet/installer:Patch
Build failure on macOS due to missing ILAsm/ILDAsm. This seems to be common issue on Linux too. The odd thing though is that
RuntimeOsxArm64MicrosoftNETCoreILAsmVersionexists butRuntimeOsxX64MicrosoftNETCoreILAsmVersiondoesn't, so needed to use Linux's version for x64. Not sure if this should be added, or if this is a .NET packaging issue that will be fixed. (EDIT: In 6.0.103, need to use Linux versions for osx-arm64 too) e.g.Patch (v6.0.102)
Patch (v6.0.103)
Error MSB4018 while building 'installer in tarball' due to trying to find
aspnetcore-runtime-internalv6.0.0 rather than current. Need to find out why this is happening. The hack done is changeMicrosoftAspNetCoreAppRuntimePackageVersiontoMicrosoftAspNetCoreAppRuntimewinx64PackageVersioninsidesrc/installer.*/src/redist/targets/GenerateLayout.targetsosx-x64as looking for v6.0.2Needed to introduce GNU sed rather than default BSD sed. Not too important and can keep as build dependency, but may want to document if it remains hard requirement. The problem is due to
sed -iusage in https://github.com/dotnet/arcade/blob/main/eng%2FSourceBuild.props#L38sed -iusage in dotnet/arcade@b8007eeTemporary issue but need to manually remove
src/nuget-client.*/eng/source-build-patches/0001-Rename-NuGet.Config*.patchsince macOS is case-insensitive OS. Would be good to be able to identify patches that are platform-compatible and have source-build skip them. Otherwise, Homebrew can continue removing incompatible patches as necessary.