-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Enable x86 AOT compilation for components build #105909
Conversation
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change looks good.
I think there is a separate question whether we should be building win-x86 ilc and crossgen2 binaries at all. I have tried to compile hello world using win-x86 ilc from .NET 9 P6 SDK and the build insists on cross-compiling using win-x64 ilc ("Add a PackageReference for 'runtime.win-x64.Microsoft.DotNet.ILCompiler' to allow cross-compilation for x86"). cc @filipnavara
That’s somewhat unexpected. It was possible to use for building the tests last time I tried. It was not necessarily a good experience since it was prone to run out of virtual memory on any bigger inputs. |
We use custom setup for tests, so I can believe that it is possible to use it for tests. I was looking at it from the user point of view. As far as I can tell, there is no way for regular user project files to use the win-x86 ilc binary. |
@jkotas, second commit fixes the publishing issue you described; when dotnet.exe or ilc.exe is x86, running (emulating) on x64 or arm64 machine. x86 dotnet.exe or ilc.exe on x86 windows were working fine with p6, so it wasn't widespread. |
src/coreclr/nativeaot/BuildIntegration/Microsoft.DotNet.ILCompiler.SingleEntry.targets
Outdated
Show resolved
Hide resolved
This reverts commit e0b50fa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There were a couple issues popping up that seemed to be caused by low frequency bugs in the preview 6 SDK. I was evaluating if we could roll it back, while monitoring the build. Overall, I don’t think we should roll back. The issues most commonly blocking the build don’t seem to be ones that would be fixed by a rollback, and we’re close to p7. I think it’s fine to merge this. |
Thank you! Merging! |
Now that global.json is pointing to p6 (which has an SDK fix for win-x86), lets try enabling it.