Add OpenHarmony (OHOS) target support#432
Conversation
shared_memory 0.12.4 pins nix = "0.23", which does not gate aio_*, lio_listio, FDPIC_FUNCPTRS, UNAME26, __fsword_t, ST_RELATIME etc. on target_env = "ohos" and thus fails to build for aarch64-unknown-linux-ohos. Vendor the crate at crates/vendor_shared_memory with publish = false, bump nix to 0.30 (default-features = false, features = ["fs", "mman"]), and adapt the API surface: shm_open returns OwnedFd (convert via into_raw_fd); ftruncate, fstat, and mmap take BorrowedFd; mmap takes Option<NonZeroUsize> for size and NonNull for addr; munmap takes NonNull. The vendor crate keeps the upstream package name shared_memory so fspy_shared consumes it unchanged through the workspace dependency. Workspace Cargo.toml swaps the entry from "0.12.4" to a path reference. Exit condition: delete this directory and revert to the crates.io dependency once upstream ships a release with nix >= 0.30 (tracked at https://github.com/elast0ny/shared_memory-rs). Same patch lives in HarmonyBrew tap at Patches/shared_memory@0.12.4/0001-ohos-nix-030.patch so both consumers stay in lockstep. Verified by cargo check -p shared_memory and cargo check -p fspy_shared on aarch64-unknown-linux-ohos (rustc 1.95 + RUSTC_BOOTSTRAP=1).
…on OHOS
OHOS musl libc.so does not export the `execveat` dynamic symbol, so two
places in the LD_PRELOAD interceptor break on aarch64-unknown-linux-ohos:
1. The intercept!() macro's compile-time signature check references
`crate::libc::execveat`, which on OHOS resolves through the `libc`
crate's gnu-only binding — missing → fails to compile.
2. At runtime, `execveat::original()` does dlsym(RTLD_NEXT, "execveat"),
which returns NULL on OHOS → calling the resulting function pointer
segfaults.
Add a syscall-backed shim in `crate::libc` cfg-gated to target_env = "ohos"
so the macro's signature check resolves, and at the interceptor's
fallthrough site replace `execveat::original()` with the shim on the same
cfg. `SYS_execveat` is reliably defined for aarch64-linux-ohos (libc 0.2
includes the constant); the preflight `c2_sys_execveat` probe confirms
the syscall works on both ci-runner OHOS and HarmonyOS userspace.
Permanently locked: the preflight `c1_execveat_sym` probe fails on both
tracks, so the extern-decl path can never work on OHOS musl. This commit
is the only safe route as long as upstream `libc` does not add an OHOS
binding.
…ux-ohos
aarch64-unknown-linux-ohos is a rustc tier-3 target. The existing clippy job
runs against the linux-gnu host, so OHOS-cfg-gated code paths (vendor
shared_memory's nix 0.30 patch, fspy_preload_unix's execveat syscall shim,
and the `target_env = "ohos"` branches in the unix-shared crates) never see
type-checking from CI.
Add a `check-ohos` job that:
* pulls the workspace-pinned nightly toolchain via setup-rust;
* adds the aarch64-unknown-linux-ohos rustup target;
* runs `cargo check --locked --target aarch64-unknown-linux-ohos` scoped
to `shared_memory`, `fspy_shared`, `fspy_shared_unix`, and
`fspy_preload_unix` with `RUSTFLAGS=-D warnings`.
The check is package-scoped rather than `--workspace` because `vite_task`'s
build script downloads host-arch binaries that are unrelated to the OHOS
cfg surface, and expanding scope would add brittleness without surfacing
OHOS-specific code paths. The job is wired into the `done` aggregator so
PRs cannot merge while the OHOS surface fails to type-check.
This is a check-only job: no `cargo build`, no test execution. OHOS lacks a
GitHub Actions runner with a HarmonyOS kernel, so end-to-end smoke tests
remain the responsibility of HarmonyBrew's downstream verification.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
The PR description is full of nonsense. Can you explain to me why you need vite-task on OpenHarmony / HarmonyOS? Vite task is currently being consumed in Vite+, it is not a standalone tool. |
|
Fair on the description — I'll rewrite it. Let me answer the "why" first since that's the load-bearing question. OpenHarmony / HarmonyOS Next is a real target with shipping JS tooling: rolldown publishes You're right that vite-task isn't standalone. The reason this PR touches vite-task and not just vite-plus is mechanical: vite-plus's NAPI binding compiles vite-task crates directly (via the
The companion vite-plus PR (release matrix entries for the two OHOS triples) is ready as a draft branch — I'll open it the moment this one merges, so the chain is visible end-to-end. Without that PR there's no Happy to split the three commits into three PRs if any is controversial in isolation, but I'd prefer to land them together since one without the others doesn't actually unblock the build. Rewriting the description now to lead with this motivation. |
|
Sorry this is still a slop response which is not answering the question "why you need vite-task on OpenHarmony / HarmonyOS". Given Vite+ has not been stabilized yet, we will put this on hold. Also, we probably don't want to vendor the |
|
I'm working on HarmonyOS Next tooling and want vite-plus available there. The vite-task touches exist only because vite-plus's NAPI binding compiles vite-task crates directly (via the Mapping each commit in this PR to vite-plus's compile path: c311dd0 (shared_memory vendor with nix 0.30) is required because vite-plus's The OHOS NDK genuinely doesn't export The vendored shared_memory is only there because 0.12.4 pins nix 0.23 which has no OHOS support. If vendoring is the sticking point, the alternatives I see are upstreaming the nix bump to shared_memory itself, or replacing it in-tree with a thin shm_open+mmap (Unix) / CreateFileMappingW (Windows) wrapper — the API surface vite-task actually uses is just Shmem + ShmemConf with size/os_id/create/open. Any preference there? |
2 participants
Why
OpenHarmony / HarmonyOS Next is a target with shipping JS tooling support today:
rolldownships @rolldown/binding-openharmony-arm64from voidzero-dev's own release matrix,@napi-rs/clirecognises the OHOS triples natively, and the OHOS SDK GitHub Action is available. vite-plus is the asymmetric gap —npm i vite-plus` fails on OHOS because the cross-compile breaks inside vite-task crates before any vite-plus code runs.Companion vite-plus PR (release matrix entry for the two OHOS triples) ready as a draft branch; opening mmediately after this lands.
What this PR changes
Three commits, one per problem:
1.
shared_memory: bump nix 0.23 → 0.30shared_memory0.12.4 pullsnix0.23 transitively. nix 0.23 has no OHOS target gates — missingmq_*,aio_*,O_FSYNC,__fsword_t. OHOS support has been in nix since 0.27.2.
fspy: route execveat throughlibc::syscallfspy_preload_unixusesintercept!(execveat ...). The macro resolvescrate::libc::execveat, which thelibccrate does not expose fortarget_env="ohos"(NDK musl libc gates it). Replacing the direct call withlibc::syscall(SYS_execveat, ...)matches the patternlibcitself uses for syscalls without bindings, and the kernel exposesSYS_execveatnormally.3. CI: add
check-ohosjobOne job on
ubuntu-latestusingBoshen/setup-ohos-sdk@v1.0.0(the same actionrolldown/rolldownuses for OHOS CI). Runscargo check --target aarch64-unknown-linux-ohosso the cfg branches above don't bit-rot.What this PR does NOT change
Verification
Locally, on a native
aarch64-unknown-linux-ohoshost:cargo check --target aarch64-unknown-linux-ohos -p fspypassescargo check --target aarch64-unknown-linux-ohos -p shared_memorypasses (transitively pulls nix 0.30).openharmony-arm64.nodevianapi build;vp create,vp fmt,vp build,vp devall work end-to-endThe check-ohos CI job exercises the same target as part of this PR.
Out of scope
lightningcssOHOS binding — separate upstream PR@ast-grep/napiOHOS prebuild — separate upstream