[springmin]

The OpenHarmony sysroot lacks qsort_r and zstd's autodetection does not
handle it; reuse the Android ZSTD_USE_C90_QSORT workaround.

Test: native libs cross-build for openharmony-arm64.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

[springmin]

Superseded by #136194, which consolidates the remaining native-libs fixes and includes device validation (hello world, child process start, network interfaces, RSA/TLS through the OpenSSL shim).

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.

[jkotas]

Superseded by #136194, which consolidates the remaining native-libs fixes

You will need owners of multiple different areas to sign-off on the consolidated PR. It will be a very slow process vs. per-area targeted PRs.

[springmin]

Reopening: the consolidation in #136194 dropped this hunk assuming the OpenHarmony sysroot declares qsort_r, but the SDK used by the CI leg does not.

With the pinned ohos-sdk-windows_linux-public.tar.gz (6.0-Release, SHA-256 a315834ac133625efc912bd078f3e2b2550868d04aef1b5aa4f9679c8b3c9d8e), native/sysroot/usr/include/stdlib.h has no qsort_r declaration (grep qsort_r finds nothing), even though the native-libs build passes -D_GNU_SOURCE. The symbol is exported by libc, but the compile-time header does not declare it, so src/native/external/zstd/lib/dictBuilder/cover.c:333 fails:

error: call to undeclared function 'qsort_r'; ISO C99 and later do not support implicit function declarations [-Werror,-Wimplicit-function-declaration]

A cross-build of clr.runtime+libs.native (-os openharmony -arch arm64 -cross -c Release with that SDK) reproduces it; with this one-line change the same build and the shim entry-point verification complete.

If there is a preferred alternative for the pinned SDK (a header declaration or an SDK bump), I can switch to it — the hunk can be dropped once the sysroot declares qsort_r.

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.

[springmin]

Confirmed the same on the 7.0 SDK, so this is not specific to the 6.0 pin.

7.0-Release SDK (native-linux-x64-26.0.0.38-Beta, API 26):

• native/sysroot/usr/include/stdlib.h declares qsort only; there is no _GNU_SOURCE section and no qsort_r.
• A recursive grep over native/sysroot/usr/include finds no qsort_r at all.
• The sysroot's link-time libc.so stub exports qsort/bsearch but not qsort_r.

The musl source repo's include/stdlib.h does declare qsort_r under _GNU_SOURCE, but the SDK ships a reduced header without the GNU extension section, and that is what the build compiles against. The C90 fallback is therefore needed for both SDK versions, and a header declaration alone would not fix the link either.

Note

This comment was drafted with AI assistance (agent tooling) under the author's direction.