Skip to content

Support aarch64-unknown-linux-ohos (HarmonyOS): utmpx/fsext/hostid fixes and timezone pass-through #14287

Description

@YodonTan

Support aarch64-unknown-linux-ohos (HarmonyOS): utmpx/fsext/hostid fixes and timezone pass-through

Background

HarmonyOS (OpenHarmony-based, aarch64-unknown-linux-ohos) ships toybox as its system toolset. Compared with the GNU coreutils set (108 commands, which uutils mirrors 1:1), the on-device toybox provides 83 and lacks 25: arch, b2sum, base32, basenc, csplit, dir, dircolors, fold, hostid, join, numfmt, pathchk, pinky, pr, ptx, runcon, sha224sum, shuf, stdbuf, stty, sum, tsort, unexpand, users, vdir. (runcon/chcon belong to the SELinux domain and are intentionally not built — OHOS has no SELinux.)

This change is the minimal patch set required to build uutils/coreutils natively on HarmonyOS (cargo build --no-default-features --features feat_os_unix and make build both pass, verified on a HarmonyOS PC, kernel HongMeng 1.13.0 aarch64).

Patch summary (verified root causes)

File Root cause Change
src/uucore/src/lib/features/utmpx.rs OHOS libc has no glibc-prefixed __UT_HOSTSIZE/__UT_LINESIZE/__UT_NAMESIZE constants; the OHOS SDK libc.so no longer exports setutxent/getutxent/endutxent/utmpxname (linker: undefined symbol) Route OHOS through the musl (UT_*) constant branch; provide same-signature stub functions (no-op / null, identical musl semantics) gated by #[cfg(target_env = "ohos")]. Existing musl allow(deprecated) attributes and all non-OHOS paths are untouched.
src/uucore/src/lib/features/fsext.rs statfs.f_type is u64 on OHOS (musl-like libc), falling into the i64 branch → E0308 Include OHOS in the musl try_into().unwrap() branch.
src/uu/hostid/src/hostid.rs gethostid is not exported by the OHOS SDK libc OHOS-local implementation: read /etc/hostid, else FNV-1a hash of the hostname (glibc semantics). Non-OHOS keeps libc::gethostid.
src/uu/date/src/date.rs jiff's TimeZone::try_system() only reads /etc/localtime / zoneinfo dirs, none exist on OHOS → always falls back to UTC (±0 offset vs system +08:00) OHOS-only ohos_system_zone(): pass through the system time zone ID from OH_TimeService_GetTimeZone and resolve it via embedded IANA tzdata (jiff-tzdb) with TimeZone::tzif, preserving DST rules and historical transitions. Call sites are #[cfg(target_env = "ohos")]-gated; non-OHOS code paths are byte-identical to upstream.
src/uu/date/Cargo.toml jiff needs tzdata to resolve the ID [target.'cfg(target_env = "ohos")'.dependencies] jiff-tzdb = "0.1" (OHOS-only).
Cargo.lock new dependency + jiff-tzdb (repo tracks the lockfile).

Build

Standard upstream flow, unix default feat_os_unix (96 commands; no selinux/systemd_logind):

export PATH="$HOME/.bitfun-ccshim:$HOME/.harmonybrew/bin:$PATH"   # cc→OHOS clang, ar→llvm-ar
make build      # per-command binaries → target/debug/<cmd>
make build MULTICALL=y   # multi-call → target/debug/coreutils

Verification (on-device, all passed)

Check Command Expected
System timezone date "+%F %T %z %Z" matches system date: +0800 CST
tzdata DST history date -d 1987-06-01 "+%z %Z" +0900 CDT (China DST era 1986–1991)
Missing commands printf 'hello coreutils for HOS' | b2sum 128 hex
Negative (utmpx stub) who; users empty output (no utmp data source on OHOS, graceful degradation)
SELinux runcon not built (no SELinux on OHOS)

Known limitations (runtime degradation, not regressions)

  • who/uptime/users/pinky: OHOS keeps no login session records; the utmpx stubs yield empty results (uptime still reads /proc).
  • cp --preserve: sandbox restricts xattr/timestamp writes; uutils reports strictly (toybox silently skips).
  • System dirs like / are subject to the app-sandbox read restrictions.

Implementation

In fork YodonTan/coreutils, branch ohos-pr (single commit 85de24e1c) — code only; documentation lives in this issue and the PR. Happy to iterate on CI (a aarch64-unknown-linux-ohos workflow would mirror android.yml/freebsd.yml).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions