-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add special Mac Catalyst values for mtriple to MonoAOTCompiler.props #57687
Add special Mac Catalyst values for mtriple to MonoAOTCompiler.props #57687
Conversation
Effectively, we are correctly saying "build a Mac Catalyst app from runtime and these `-llvm.o` files, but the `-llvm.o` files are not correctly being built in a Mac Catalyst compatible way, resulting in the error ``` ld: building for Mac Catalyst, but linking in object file built for , file '/Users/filipnavara/Projects/llvmbug/obj/Debug/net6.0-maccatalyst/maccatalyst-arm64/nativelibraries/aot-output/arm64/llvmbug.dll.llvm.o' ``` The target platform parameter gets passed around a LOT - `src/tasks/AotCompilerTask/MonoAOTCompiler.props` specifies `<MonoAOTCompilerDefaultAotArguments Condition="'$(TargetArchitecture)' == 'arm64'" Include="mtriple=arm64-ios" />` which passes through to MonoAOTCompiler.cs task which passes through to the `mono --aot=llvmopts=mtriple=arm64-ios` flag, which is processed by `src/mono/mono/mini/aot-compiler.c` and eventually regurgitated as `llc -mtriple=arm64-ios -march=aarch64`, which results in .o files which lack the required annotations to be considered Catalyst compatible. Thankfully, it seems that `llc` accepts `clang`'s `-target` triplet values as valid for `-mtriple`, so passing through Catalyst specific values for `mtriple` in `MonoAOTCompiler.props` results in .o files which are correctly linked later by `clang` during the AppleAppBuilder task. It's slow though! 🙀 Fixes dotnet#57589
This definitely looks like a good first step. I am still trying to figure out how would this affect Xamarin builds though. The .props file doesn't seem to end up in any of the SDKs and neither does any mention of Should the default definitions be part of a workload? If not, does it mean that equivalent change needs to be done on Xamarin side here? |
@filipnavara Xamarin iOS/Mac doesn't use the MonoAOTCompiler msbuild task yet, only Android does. So this will just fix testing in the dotnet/runtime repo but will need the same change in xamarin-macios repo. |
…otnet#57687) Effectively, we are correctly saying "build a Mac Catalyst app from runtime and these `-llvm.o` files, but the `-llvm.o` files are not correctly being built in a Mac Catalyst compatible way, resulting in the error ``` ld: building for Mac Catalyst, but linking in object file built for , file '/Users/filipnavara/Projects/llvmbug/obj/Debug/net6.0-maccatalyst/maccatalyst-arm64/nativelibraries/aot-output/arm64/llvmbug.dll.llvm.o' ``` The target platform parameter gets passed around a LOT - `src/tasks/AotCompilerTask/MonoAOTCompiler.props` specifies `<MonoAOTCompilerDefaultAotArguments Condition="'$(TargetArchitecture)' == 'arm64'" Include="mtriple=arm64-ios" />` which passes through to MonoAOTCompiler.cs task which passes through to the `mono --aot=llvmopts=mtriple=arm64-ios` flag, which is processed by `src/mono/mono/mini/aot-compiler.c` and eventually regurgitated as `llc -mtriple=arm64-ios -march=aarch64`, which results in .o files which lack the required annotations to be considered Catalyst compatible. Thankfully, it seems that `llc` accepts `clang`'s `-target` triplet values as valid for `-mtriple`, so passing through Catalyst specific values for `mtriple` in `MonoAOTCompiler.props` results in .o files which are correctly linked later by `clang` during the AppleAppBuilder task. It's slow though! 🙀 Fixes dotnet#57589
…t and test fixes for Android (#58841) Manual backport of #57208, #58519, #58562, #58210, #57732, #58428, #58586, #58745, #57687 to release/6.0 Numerous test suites have been failing for iOS/tvOS/MacCatalyst consistently on CI without useful logs as to why. Moreover, some of these suites pass locally. This PR looks to reduce the failures on CI by skipping the problematic suites Skips test suites logged in #53624 ActiveIssues #58440 #58418 #58367 #58584 Co-authored-by: Mitchell Hwang <mitchell.hwang@microsoft.com> Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com> Co-authored-by: Jo Shields <directhex@apebox.org>
Effectively, we are correctly saying "build a Mac Catalyst app from runtime and these
-llvm.o
files, but the-llvm.o
files are not correctly being built in a Mac Catalyst compatible way, resulting in the errorThe target platform parameter gets passed around a LOT -
src/tasks/AotCompilerTask/MonoAOTCompiler.props
specifies<MonoAOTCompilerDefaultAotArguments Condition="'$(TargetArchitecture)' == 'arm64'" Include="mtriple=arm64-ios" />
which passes through to MonoAOTCompiler.cs task which passes through to themono --aot=llvmopts=mtriple=arm64-ios
flag, which is processed bysrc/mono/mono/mini/aot-compiler.c
and eventually regurgitated asllc -mtriple=arm64-ios -march=aarch64
, which results in .o files which lack the required annotations to be considered Catalyst compatible.Thankfully, it seems that
llc
acceptsclang
's-target
triplet values as valid for-mtriple
, so passing through Catalyst specific values formtriple
inMonoAOTCompiler.props
results in .o files which are correctly linked later byclang
during the AppleAppBuilder task.It's slow though! 🙀
Fixes #57589