On Sat, Aug 29, 2026, at 5:23 AM, [email protected] wrote: > config.guess cannot identify HarmonyOS / OpenHarmony. On such a device > `uname -s` reports "HarmonyOS" rather than "Linux", so the script > falls through to "unable to guess system type" and exits non-zero. ... > OpenHarmony is a Linux-kernel-based operating system. HarmonyOS is an > OS that implements POSIX interfaces and achieves full Linux ABI&API > compatibility (see details in OSDI'24 "Microkernel Goes General ..."). > Both systems' userspace uses musl libc. ... > So this is analogous to the Android support config.guess already > has (it sets LIBC=android and emits `*-linux-android*` tuples). I'd > like to propose the same treatment for HarmonyOS/OpenHarmony: emit > `$UNAME_MACHINE-unknown-linux-ohos`.
Are you sure it is necessary to call this -linux-ohos and not -linux-musl? System identification tuples should, in principle, only be specific enough to identify the CPU, object file format, kernel, and C library. What needs to behave differently in an "linux-ohos" configuration than a "linux-musl" configuration *that cannot be directly probed for*? > One more, independent robustness issue: on HarmonyOS the sandbox makes > `/tmp` read-only and also blocks writing to `$HOME` This is a bug in the sandbox configuration. If `/tmp` is not available, the environment variable `TMPDIR` must be set to (the absolute pathname of) a writable directory suitable for storage of temporary files. Many other things will break if this is not corrected. zw
