OHOS: verify Alpine-built .so in dockerharmony (1.6.58.6)

[ronaldtse]

What

Replace the unverified "Alpine-built bytes labeled as OHOS" approach with dockerharmony-based empirical verification. Simpler than PR #11's OHOS NDK cross-compile (which hit repeated issues), and provides actual evidence the bytes work in OHOS userland.

Why

The 1.6.58.4/.5 OHOS gem shipped Alpine-built musl arm64 bytes under the OHOS platform label, based on an unverified assumption that "same dynamic linker path = byte-compatible". PR #11 tried to fix this via OHOS NDK cross-compile but hit repeated issues across 5 CI iterations:

• sysroot path was llvm-19/sysroot/aarch64-linux-ohos/usr/lib, not llvm-19/ohos-sysroot/usr/lib/...
• OHOS clang didn't auto-detect multiarch library paths
• zlib not shipped as separate libz.so in the OHOS sysroot
• ls | head triggered pipefail exit

Each fix revealed a new issue. The complexity tax of cross-compilation for libpng (which uses CMake and requires zlib as an external dependency) isn't paying for itself.

dockerharmony (https://github.com/hqzing/dockerharmony) provides real OHOS userland in a Docker container. Alpine-built aarch64-linux-musl binaries run natively in it. We can use this to empirically verify our Alpine-built .so actually loads and works in OHOS — without any cross-compile machinery.

How

Files added

• ext/ohos/smoke-test.c — minimal libpng round-trip test (2x2 RGBA encode → decode → byte comparison via the simplified API).
• ext/ohos/verify-prepare.sh — runs inside the Alpine container (where we already have gcc + libpng headers). Compiles smoke-test.c against the freshly built libpng16.so with rpath=$ORIGIN, copies the .so + libz.so next to the binary, outputs to $PWD/ohos-verify/.

CI changes (build.yml + release.yml)

The aarch64-linux-ohos entry in build_musl now does two things inside the Alpine container:

1. The existing gem build + Alpine-Ruby smoke test (unchanged).
2. NEW: runs verify-prepare.sh to produce the dockerharmony artifacts.

A new step Verify in dockerharmony (OHOS userland) runs after the Alpine container:

• Gated on matrix.platform == 'aarch64-linux-ohos'.
• Pulls ghcr.io/hqzing/dockerharmony:latest (cached on the arm64 runner).
• Runs LD_LIBRARY_PATH=. ./smoke-test inside the container, with the artifacts dir mounted.
• Build fails if the smoke test fails.

The dockerharmony image is real OHOS mini rootfs (musl + toybox + mksh), running on the arm64 runner natively. Not qemu emulation. If the smoke test passes there, the bytes actually work in OHOS userland.

What this verifies

• ✅ The OHOS dynamic linker (/lib/ld-musl-aarch64.so.1) loads our Alpine-built .so without errors.
• ✅ libpng's simplified API round-trips encode→decode with matching pixel bytes.
• ✅ All of this happens inside real OHOS userland, not an emulated sysroot.

What this does NOT verify

• Real OHOS hardware. dockerharmony runs the OHOS rootfs on a Linux kernel; real devices may have additional constraints (SELinux policies, code signing enforcement at the kernel level).
• Code signing. OHOS requires .so files to be code-signed for runtime loading on production devices. dockerharmony skips this check (it's a dev container). Users on real OHOS hardware may need to sign the .so via binary-sign-tool sign -selfSign 1 themselves. Documented in CHANGELOG. A future release may add automatic signing if a hardware user reports breakage.

Why not the ohos-node approach (OHOS NDK + bundled zlib)?

Considered and rejected (for now). ohos-node's pattern works for Node.js because Node bundles its own zlib + uses gyp configure that handles cross-compile cleanly. libpng uses CMake (more demanding on toolchain config) and requires zlib as an external find_package(ZLIB) — the OHOS sysroot doesn't ship libz.so as a separate file, so we'd need to also build zlib from source with the NDK. That's ~250 lines of code, a new zlib source URL+sha256 to maintain, and the result still needs verification (which would be the same dockerharmony check).

If a real OHOS hardware user reports signing or symbol issues, we can revisit the NDK approach as a follow-up — with the lessons learned from PR #11 and a bundled zlib build step.

Test plan

• bundle exec rake — 132 specs pass, rubocop clean (no source/test changes)
• CI: Alpine build for aarch64-linux-ohos succeeds, produces ohos-verify/ artifacts.
• CI: dockerharmony container pulls successfully on ubuntu-24.04-arm.
• CI: smoke-test outputs OK inside dockerharmony.
• CI: all 11 platform gems still build (10 native + source ruby).

Version

Bumps LIBPNG_RUBY_ITERATION 5 → 6. Replaces the regression acknowledged in CHANGELOG (1.6.58.4/.5 used Alpine-built bytes for OHOS without verification).

[ronaldtse]

Closing in favor of PR #13 (proper OHOS NDK cross-compile). The dockerharmony verification step is reused; the build approach changes from 'Alpine-built bytes labeled OHOS' to 'NDK-built bytes signed with binary-sign-tool'. smoke-test.c is carried over. See TODO.ohos/ in the new branch for the architecture.