-
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
Use system brotli on Unix non-portable builds #107225
Conversation
src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets
Outdated
Show resolved
Hide resolved
…e.Unix.targets Co-authored-by: Jan Kotas <[email protected]>
@@ -164,6 +164,11 @@ The .NET Foundation licenses this file to you under the MIT license. | |||
<NativeSystemLibrary Include="crypto" /> | |||
</ItemGroup> | |||
|
|||
<ItemGroup Condition="'$(UseSystemBrotli)' != 'false' and Exists('$(IlcSdkPath)nonportable.txt')"> |
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.
Can we extend this with something that is similar to https://github.com/dotnet/runtime/pull/107166/files#r1739122333? Then source-build can be built with bundled or system brotli.
Otherwise we need to add --cmakeargs -DCLR_CMAKE_USE_SYSTEM_BROTLI=true
(similar to what is in the diff in #107020 (comment)) and source-building requires system brotli.
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.
For .NET 10, we will get it with #107166.
For .NET 9, it would require build refactoring that is hard to justify for a backport at this point.
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.
ok, then we need to add something that sets CLR_CMAKE_USE_SYSTEM_BROTLI=true
so maintainers provide brotli in their non-portable builds.
Without it, the brotli the bootstrap build will work (since Microsoft's portable SDK doesn't have a nonportable.txt
breadcrumb) but successive builds using the produced non-portable SDK won't, because NativeAOT will fail when trying to find brotli on a system that doesn't provide it.
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.
Why is this not sufficient https://github.com/dotnet/runtime/blob/main/eng/DotNetBuild.props#L91 ?
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.
That doesn't do anything unless the maintainer builds the vmr with --with-system-libs brotli
.
If he doesn't add it, his bootstrap build works, but he is not aware that successive builds using that SDK will fail unless he provides brotli.
By adding CLR_CMAKE_USE_SYSTEM_BROTLI=true
for non-portable, we make this issue visible also on the bootstrap build.
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.
That doesn't do anything unless the maintainer builds the vmr with --with-system-libs brotli.
Are there any distros that do not want to use --with-system-libs brotli
? I think that the conversation in #107020 suggested that all interested distro builds want to use --with-system-libs brotli
.
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.
Yes, there are no maintainers that have objected to using system brotli, and we are assuming brotli to be a common available system library.
Note that this change will also require a brotli development package to be added to the source-build CI jobs.
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.
By that you mean added to the container?
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.
Yes.
#107225 (comment) needs to be tackled first. |
@tmds Have you validated that this fix works locally? I can start upgrading the containers separately. |
Can we address #107225 (comment) first? I'll validate this by building the vmr, and then building it again using the output of the first build. |
By this, I mean: add something to |
@agocke I've validated this change, and it is working as expected both for the portable publish as the non-portable publish. |
It looks like this works now, after the update to the containers. From the build log:
|
@tmds This is now waiting on your review, let me know if there's anything else needed to unblock the build. |
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! Thanks!
@jkotas Anything else I should cover? |
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
@jkoritzinsky This change should be reverted in your PR |
/backport to release/9.0 |
Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/10819302776 |
This reverts commit 3979ef8.
Co-authored-by: Jan Kotas <[email protected]>
This is failing Android build in SDK codeflow: https://dev.azure.com/dnceng-public/public/_build/results?buildId=818433&view=logs&jobId=66673ce3-9c46-54b2-cf79-862a2d55b22a&j=66673ce3-9c46-54b2-cf79-862a2d55b22a&t=f73a763b-d161-54c1-b189-48197f51b0b6
cc @lewing |
Fix: dotnet/arcade#15107. After merging, we will need to trigger https://github.com/dotnet/dotnet-buildtools-prereqs-docker/tree/main/src/azurelinux/3.0/net9.0/cross/amd64 and then https://github.com/dotnet/dotnet-buildtools-prereqs-docker/tree/main/src/azurelinux/3.0/net9.0/cross/android build. cc @mthalman |
These images have been published with the updates. |
Co-authored-by: Jan Kotas <[email protected]>
Fixes #107020