[AI Readability Summary]
Low-level HarmonyOS PC development mainly revolves around two toolchains: OpenHarmony SDK and HarmonyOS SDK. Both target the
aarch64-linux-ohostriple. This article explains their structure, download strategy, cross-compilation, and native compilation workflows, while addressing common issues such as environment setup complexity, poor CI compatibility, and missed code signing. Keywords: HarmonyOS PC, OpenHarmony SDK, cross-compilation.
The technical specification snapshot clarifies the baseline
| Parameter | Details |
|---|---|
| Target Platform | HarmonyOS PC / HongMeng PC |
| Primary Languages | C, C++, Shell |
| Target Triple | aarch64-linux-ohos |
| Compilers | OpenHarmony LLVM, BiSheng |
| Distribution | Official releases, community daily build pipelines |
| Core Dependencies | clang, binary-sign-tool, curl, unzip |
| Star Count | Not provided in the source material |
| Typical Use Cases | Cross-compilation, native compilation, CI/CD integration |
HarmonyOS PC actually provides two usable toolchains
From the compiler’s perspective, both OpenHarmony and HarmonyOS ultimately target the same triple: aarch64-linux-ohos. That means at the low-level C/C++ compilation stage, the toolchain first identifies the target platform rather than the commercial distribution identity.
Developers currently have access to two toolchains: OpenHarmony SDK and HarmonyOS SDK. The former is maintained by the open source community, while the latter is maintained by Huawei. However, they are not mutually exclusive alternatives. Instead, the downstream distribution includes the upstream one.
The HarmonyOS SDK actually contains the OpenHarmony SDK internally
Inside a typical HarmonyOS SDK archive, you will usually find two subdirectories: openharmony and hms. The openharmony directory contains the open source SDK, while hms contains closed-source incremental capabilities such as HMS-related components and the BiSheng compiler.
HarmonyOS SDK/
├── openharmony/ # Open source SDK directory
└── hms/ # Huawei-specific capabilities and the BiSheng compilerThis structure shows that the HarmonyOS SDK is better understood as an enhanced distribution rather than a completely separate low-level stack.
Most low-level developers prefer the OpenHarmony SDK
Although the BiSheng compiler offers stronger performance potential, many developers still default to the OpenHarmony SDK. The core reason is not missing functionality, but engineering efficiency and distribution mechanics.
First, both toolchains share a highly similar LLVM foundation, so the difference in basic compilation tasks for aarch64-linux-ohos is limited. Second, downloading the HarmonyOS SDK depends more heavily on an account system and graphical distribution channels, which makes it less friendly for server environments and automated pipelines.
The OpenHarmony SDK is better suited for automation and rapid iteration
The community pipeline provides public daily build artifacts, allowing developers to pull the latest version directly through scripts and quickly verify features and fixes. In contrast, commercial SDKs usually follow the vendor’s release rhythm, which makes updates and acquisition workflows heavier.
# Pull the SDK artifact directly in CI or on a server
curl -fL -o ohos-sdk-full.tar.gz <OpenHarmony-SDK-URL>
# Extract the archive and enter the corresponding platform directory
mkdir -p ~/ohos-sdk && tar -zxf ohos-sdk-full.tar.gz -C ~/These commands demonstrate the automation-friendly nature of the OpenHarmony SDK, which fits scripted builds and continuous integration.
The same SDK appears in two forms on HarmonyOS PC
Depending on where you build, the OpenHarmony SDK is available as a cross-compilation toolchain or a native compilation toolchain. The former means compiling on Linux or a workstation and running on HarmonyOS PC. The latter means compiling and running directly on HarmonyOS PC.
If the archive contains directories such as linux, windows, or darwin, it usually indicates a cross-compilation toolchain. If it contains an ohos directory, it corresponds to a native compilation toolchain.
You should prioritize directory layout and signing status when selecting artifacts
The article’s practical conclusion is important: for cross-compilation, prefer ohos-sdk-full; for native compilation, prefer ohos-sdk-public_ohos. The reason is that some native binaries inside certain full packages are unsigned and cannot run directly on HarmonyOS PC.
Official distribution channels determine long-term toolchain maintainability
Two official sources are recommended: the OpenHarmony Release documentation and the community daily build pipeline. The former is better for stable releases, while the latter is better for tracking daily builds.
If you are unsure which one to choose, remember this minimal rule: use ohos-sdk-full for server-side cross-compilation, and use ohos-sdk-public_ohos for on-device local builds. This avoids most directory layout and signing issues.
The cross-compilation workflow can be implemented quickly on Ubuntu servers
Cross-compilation consists of three core steps: download and extract the SDK, add clang and the signing tool to PATH, then compile and sign with the target triple.
# Download and extract the OpenHarmony SDK
curl -fL -o ohos-sdk-full.tar.gz https://cidownload.openharmony.cn/version/Daily_Version/OpenHarmony_7.0.0.23/20260501_000355/version-Daily_Version-OpenHarmony_7.0.0.23-20260501_000355-ohos-sdk-full.tar.gz
tar -zxf ohos-sdk-full.tar.gz -C ~/
rm -f ~/daily_build.log ~/manifest_tag.xml # Remove bundled auxiliary files
cd ~/ohos-sdk/linux
unzip -uq native-*.zip # Extract compiler components
unzip -uq toolchains-*.zip # Extract toolchain components
export PATH=~/ohos-sdk/linux/native/llvm/bin:~/ohos-sdk/linux/toolchains/lib:$PATHThis script prepares the cross-compilation environment and serves as the foundation for subsequent builds.
A minimal C program can validate both the toolchain and signing workflow
#include <stdio.h>
int main() {
printf("Hello, HongMeng PC!\n"); // Verify that the target program can run on HarmonyOS PC
return 0; // Exit normally
}This code validates whether the compiler, target triple, and runtime environment are all working correctly.
clang --target=aarch64-linux-ohos my_program.c -o my_program # Compile for the HarmonyOS PC target platform
binary-sign-tool sign -selfSign 1 -inFile my_program -outFile my_program # Sign the binary before executionThese two commands generate the executable and sign it. Both steps are required.
Native compilation is better suited for on-device validation and lightweight development
In the HiShell environment on HarmonyOS PC, you can also compile programs directly with the native toolchain. This mode is useful for quickly validating platform behavior and troubleshooting device-specific issues without repeatedly uploading binaries.
# Download and extract the native SDK
curl -fL -o ohos-sdk-public_ohos.tar.gz https://cidownload.openharmony.cn/version/Master_Version/ohos-sdk-public_ohos/20260330_020501/version-Master_Version-ohos-sdk-public_ohos-20260330_020501-ohos-sdk-public_ohos.tar.gz
mkdir -p ~/ohos-sdk
tar -zxf ohos-sdk-public_ohos.tar.gz -C ~/ohos-sdk
cd ~/ohos-sdk/ohos
unzip -uq native-*.zip # Extract the native compiler
unzip -uq toolchains-*.zip # Extract signing and supporting tools
export PATH=~/ohos-sdk/ohos/native/llvm/bin:~/ohos-sdk/ohos/toolchains/lib:$PATHThis script initializes the local compilation environment on HarmonyOS PC.
clang my_program.c -o my_program # Compile directly on the local machine
binary-sign-tool sign -selfSign 1 -inFile my_program -outFile my_program # Generate a runnable signature
./my_program # Run the programThese commands show the core difference between native and cross-compilation: whether you need to explicitly declare the target triple.
The image area is decorative rather than a core technical diagram
AI Visual Insight: This image indicates that the article was indexed by a technical community platform. It serves as a page-status visual cue and does not convey key technical information such as toolchain structure, compilation flow, or system architecture.
Toolchain selection is fundamentally about engineering efficiency
If your focus is low-level C/C++ adaptation, third-party library porting, CI integration, and rapid iteration, the OpenHarmony SDK is currently the more practical default choice. If you need Huawei-specific closed-source capabilities or more aggressive compilation optimizations, then consider the HarmonyOS SDK and the BiSheng compiler.
FAQ
Why is the OpenHarmony SDK more commonly used for low-level HarmonyOS PC development?
Because it is easier to download automatically, better suited for CI/CD, updates faster, and already provides sufficiently stable baseline compilation support for aarch64-linux-ohos.
What is the biggest difference between cross-compilation and native compilation?
Cross-compilation generates HarmonyOS PC executables on another system and usually requires explicitly specifying --target=aarch64-linux-ohos. Native compilation performs the build directly on HarmonyOS PC.
Why must I sign the binary after compilation?
Because HarmonyOS PC enforces code-signing checks for executables and related libraries. If a binary is unsigned or incorrectly signed, it typically cannot run correctly.
Core summary: This article systematically explains the two toolchains available for low-level HarmonyOS PC development, clarifies the inclusion relationship between OpenHarmony SDK and HarmonyOS SDK, shows why developers more often choose the upstream SDK, and provides practical examples for downloading, configuring, signing, and running both cross-compilation and native compilation workflows.