Put brotli on the FetchContent plan (Try 2) #109707
Conversation
|
/azp run runtime-extra-platforms, runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 2 pipeline(s). |
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries |
…maintainer to set the paths correctly. Fixes dotnet#109105
… always side-by-side (and we don't need to add it to the Mono build)
|
/azp run runtime-ios, runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
jkoritzinsky
requested review from
steveisok,
vitek-karas and
MichalStrehovsky
as code owners
| @@ -169,6 +171,14 @@ The .NET Foundation licenses this file to you under the MIT license. | |||
| <NativeLibrary Condition="'$(UseSystemZlib)' != 'true'" Include="$(IlcSdkPath)libz.a" /> | |||
| </ItemGroup> | |||
|
|
|||
| <!-- brotli must be added after System.IO.Compression.Native and brotlicommon must be added last, order matters. --> | |||
| <ItemGroup Condition="'$(UseSystemBrotli)' != 'true'"> | |||
| <NativeLibrary Include="$(IlcFrameworkNativePath)libbrotlienc.a" /> | |||
There was a problem hiding this comment.
We get libz from IlcSdkPath. What's the reason for brotli to be different?
There was a problem hiding this comment.
Getting libz from the IlcSdkPath works well because we end up building zlib with the Mono runtime and we build the zlib libs as part of the NativeAOT runtime build (that builds the libraries static libs).
For brotli, Mono doesn't currently build brotli in any capacity or link it into their runtime at all. As a result, putting the brotli libs into the ILC SDK and not into the "libraries native components static libs" folder causes Mono-based static linking scenarios to fail as they don't have anywhere to get the brotli symbols from. In particular, we hit this on iOS, a platform where we decided to continue using the system zlib implementation due to size constraints and linking considerations.
There was a problem hiding this comment.
The brotli libs are still under IlcSdkPath on Windows. Is that right?
It does not look right to me that configuration of Mono targets is forcing a directory structure of NAOT packages.
There was a problem hiding this comment.
The brotli libs are next to the Compression.Native libs for all platforms. On Windows this is IlcSdkPath, on non-Windows it is not.
There was a problem hiding this comment.
Should we have libz next to Compression.Native too to have some sort of consistency?
There was a problem hiding this comment.
I can try giving that a shot now that we aren't going to use a vendored zlib on mobile platforms.
Unlike the first try, don't ship the brotli libs in two places. Since no runtime references the brotli components, only build brotli alongside the native libs components for each platform.