-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Don't copy coreclr version of coreclr and SPCL to core_root when targeting mono #76890
Conversation
Tagging subscribers to this area: @hoyosjs Issue DetailsFixes #72114 (hopefully)
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsFixes #72114 (hopefully) When generating
|
I think we still need to copy over corerun for the Mono builds. It might be worth moving the source for corerun to somewhere under |
Ugh, right. forgot that was from coreclr build/artifacts. |
9eedef7
to
91c6146
Compare
91c6146
to
31c6577
Compare
Failure is #76801. Checked the binlogs from the build to make sure we no longer have double writes when creating core_root for mono. We only copy the mono versions of |
@dotnet/runtime-infrastructure anyone want to take a look here? |
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.
LGTM overall even though I probably still not fully grasp why you still seem to be copying around the CoreCLR version of coreclr.dll at line 178.
It's removing it from the items to copy. It currently gets included because we include the entire coreclr artifacts folder (parts of which we still need for mono) via wildcard, so that line removes that one file. |
Fixes #72114 (hopefully)
When generating
core_root
targeting mono, both the coreclr and mono versions ofcoreclr
andSystem.Private.CoreLib.dll
are being copied over. It is a race of which is last - when coreclr is last, it results in mass test failures due to the incorrectly constructedcore_root
.