Fix zlib-ng compilation on Raspberry Pi ARM32

[filipnavara]

Fixes #106584

Note that we don't lose any optimized code paths since NEON is enabled:

  -- The following features have been enabled:
  
   * CMAKE_BUILD_TYPE, Build type: DEBUG (selected)
   * ACLE_CRC, Support ACLE optimized CRC hash generation, using "-march=armv8-a+crc"
   * NEON_ADLER32, Support NEON instructions in adler32, using "-mfpu=neon"
   * NEON_SLIDEHASH, Support NEON instructions in slide_hash, using "-mfpu=neon"
   * WITH_GZFILEOP, Compile with support for gzFile related functions
   * ZLIB_COMPAT, Compile with zlib compatible API
   * WITH_SANITIZER, Enable sanitizer support
   * WITH_GTEST, Build gtest_zlib
   * WITH_OPTIM, Build with optimisation
   * WITH_NEW_STRATEGIES, Use new strategies
   * WITH_ACLE, Build with ACLE
   * WITH_NEON, Build with NEON intrinsics

On the unsupported ARMv6 Mono builds the system Zlib is used instead.

[filipnavara]

The windows-arm64 build failure is unrelated. It was fixed yesterday by #106578.

[am11]

On the unsupported ARMv6 Mono builds the system Zlib is used instead.

nit: it's a community-supported platform, not unsupported. 😉

[carlossanlop]

We were already blocking armv6 here, so I am wondering why it is not working: https://github.com/dotnet/runtime/blob/main/eng/native/configureplatform.cmake#L511-L516

[filipnavara]

We were already blocking armv6 here, so I am wondering why it is not working: https://github.com/dotnet/runtime/blob/main/eng/native/configureplatform.cmake#L511-L516

This is ARMv7 system though, so it is (correctly) not blocked.

[carlossanlop]

Thanks for the explanations. The comment seems to be descriptive enough about the mismatch.

If this is not an upstream issue in zlib-ng as you mentioned, but rather an issue in runtime, could you please then open an issue for us to continue the discussion around this mismatch and make sure we get it fixed when the time comes?

[carlossanlop]

/ba-g The CI failure in crossaot is unrelated to your PR and has already been fixed in main: #106578

[filipnavara]

could you please then open an issue for us to continue the discussion around this mismatch and make sure we get it fixed when the time comes?

I can open an issue but I don't think there's anything else to fix.

ARMv6 is community supported platform that uses system Zlib. There's no degradation from disabling this code path on the supported ARMv7 platforms since they have NEON available and zlib-ng thus gets the fast paths. We may want to double check what happens when cross-compiling but the PR should certainly not make it worse.

Using thumb instruction set in CoreCLR is conscious choice that is unlikely to be changed.

[carlossanlop]

I can open an issue but I don't think there's anything else to fix.

Alright, no problem, I trust your assessment. Do you have permission to hit the merge button or would you like me to do it?

[filipnavara]

Do you have permission to hit the merge button or would you like me to do it?

Please merge it, I don’t have the permissions. Thanks!

[carlossanlop]

I also forgot to ask: do you know if the runtime-community azp run tests the affected architecture? Asking in case we should execute a run just for peace of mind.

[filipnavara]

It should be covered by the regular runtime tests for linux-arm. If you want to be extra cautious then /azp run runtime-nativeaot-outerloop has coverage for the build and runtime paths. There are no legs to cover full build on linux-arm that’s not cross-build (AFAIK).

[carlossanlop]

All the linux-arm legs passed. I think that should be enough. Thanks.