-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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.