配套猫哥的直播PPT。以pngquant命令行移植为项目实战演示，详细介绍移植pngquant命令行到鸿蒙PC的四种实现方案及对比。

鸿蒙 PC 命令行工具迁移实战 · 直播PPT

在这里插入图片描述

文章目录

pngquant 是对 PNG 做有损压缩的命令行工具（GPL-3.0-or-later），在尽量保持观感的前提下减小体积。

pngquant仓库地址：https://github.com/kornelski/pngquant

其经典 2.x 分支以 C 语言为主，依赖：

依赖 作用
libpng 读写 PNG
zlib 压缩数据流
lcms2 色彩管理（ICC 等），对应 configure 的 --with-lcms2

源码默认从 GitHub 拉取指定 tag（本适配为 2.18.0），且需 git clone --recursive，以便带上 lib/ 下的 libimagequant 子模块（pngquant 会静态链接该库）。

移植方案总览对照表

方式 核心抽象 适合场景 长处 短处
原始工具链直接交叉编译 手搓 flags 极简项目 / 教学演示 掌控力强 依赖多时脚本难维护
Lycium++ HPKBUILD + HNP + 设备测 鸿蒙生态原生项目 贴近 OHOS 分发链 学习成本、仓库治理
vcpkg-ohos triplet + port CMake 工程 / Qt 开发者 生态庞大、一行命令 fork 过渡期；签名和 HNP 自建
build_in_harmonyos OpenDesk Skill + 知识图谱 批量移植 / 规模化 AI 加持、自动沉淀经验 依赖鸿蒙PC本机/网络环境

社区引导

📢 欢迎加入开源鸿蒙 PC 社区！
🌐 社区地址：https://harmonypc.csdn.net/
📦 三方库仓库：https://gitcode.com/OpenHarmonyPCDeveloper
🤖 AI 编译框架：https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos

一个人移植一个库，能跑就行；
一群人移植几百个库，生态就成了。

只要这个库能移植，这个库肯定能移植，就这么简单。

一 、编译环境搭建

windows下推荐WSL环境，参见博文：

在 Windows 10 上安装和使用 WSL 2 安装 Ubuntu24详细指南

鸿蒙PC生态三方软件移植：开发环境搭建及三方库移植指南

1.1 环境准备（Ubuntu 24.04）

sudo apt update
sudo apt install -y git curl cmake ninja-build gcc g++ make autoconf automake libtool yasm nasm

sudo apt install -y gettext autopoint
sudo apt install python3 python3-pip
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1

1.2下载配置ohos-sdk

工具链的获取渠道
OpenHarmony SDK 的官方获取渠道有两处：

OpenHarmony 社区 Release 文档： 每当 OpenHarmony 系统发布一个新的 Release 版本，社区都会为其提供一个 Release 文档，里面不仅提供了归档好的系统源码和系统镜像包下载链接，同样提供了配套的 OpenHarmony SDK 下载链接。

OpenHarmony 社区流水线： 从社区流水线中，不仅可以下载到正式的 Release 版本产物，还可以下载到任意一天的日构建产物。如果你不知道选哪个产物，可以这么选：交叉编译选 ohos-sdk-full；原生编译选 ohos-sdk-public_ohos。

sdk_download_url="https://cidownload.openharmony.cn/version/Daily_Version/OpenHarmony_6.1.0.27/20260111_020523/version-Daily_Version-OpenHarmony_6.1.0.27-20260111_020523-ohos-sdk-public.tar.gz"
curl -o ohos-sdk-public.tar.gz $sdk_download_url
mkdir ohos-sdk
tar -zxf ohos-sdk-public.tar.gz -C ohos-sdk

cd ~/ohos-sdk/linux
unzip native-linux-x64-6.1.0.27-Beta1.zip
unzip toolchains-linux-x64-6.1.0.27-Beta1.zip

# 将编译器与签名工具路径加入 PATH 环境变量
export PATH=~/ohos-sdk/linux/native/llvm/bin:~/ohos-sdk/linux/toolchains/lib:$PATH

这段代码的作用是从指定的 URL 下载 SDK 压缩包，然后创建一个名为 ohos-sdk 的目录，并将压缩包解压到该目录下。

创建一个简单的测试程序 my_program.c

#include <stdio.h>

int main() {
    printf("Hello, HongMeng PC!\n");
    return 0;
}

使用 ohos-sdk 中的编译器进行交叉编译，并签名

clang --target=aarch64-linux-ohos my_program.c -o my_program

binary-sign-tool sign -selfSign 1 -inFile my_program -outFile my_program

#如果需要依赖库，则可以：
# 1. 让 pkg-config 去你的目标板 sysroot 目录里找 .pc
export PKG_CONFIG_LIBDIR=/path/to/sysroot/usr/lib/pkgconfig
export PKG_CONFIG_SYSROOT_DIR=""
# 2. 在编译时，用反引号 `` 或 $() 把 pkg-config 生成的 -I 和 -L 塞给编译器
clang  main.c $(pkg-config --cflags --libs libavcodec) -o main

将这个编译好的 my_program 程序放到鸿蒙 PC 上，可正常运行

chmod +x my_program
./my_program

输出：Hello, HongMeng PC!

1.3 源码获取

#clone pngquant 源码
git clone -b 2.18.0 --recursive https://github.com/kornelski/pngquant.git

二、四种编译方案的使用对比 (手动交叉编译 / Lycium/ vcpkg-ohos /build_in_harmonyos )

方案一 手动交叉编译

2.1 编译环境脚本exports.sh

source exports.sh

使用猫哥提供的通用脚本（exports.sh），用于一键配置交叉编译环境。更多移植教程，参见猫哥个人博客：(blog.csdn.net/qq8864)

echo "hello exports,交叉编译环境配置"

## SDK路径，你唯一需要根据实际的改的地方
SDK_PATH="/root/ohos-sdk/linux"

echo "SDK_PATH:$SDK_PATH"

export OHOS_SDK="$SDK_PATH"
export HNP_PERFIX=

export COMPILER_TOOLCHAIN=${OHOS_SDK}/native/llvm/bin/

BUILD_OS=$(uname)


PYTHON=$(python --version)
echo "python  : $PYTHON"

export CC=${COMPILER_TOOLCHAIN}clang             && echo "CC      : ${CC}"
export CXX=${COMPILER_TOOLCHAIN}clang++          && echo "CXX     : ${CXX}"
export HOSTCC=${CC}                              && echo "HOSTCC  : ${HOSTCC}"
export HOSTCXX=${CXX}                            && echo "HOSTCXX : ${HOSTCXX}"
export CPP="${CXX}  -E"                          && echo "CPP     : ${CPP}"
export AS=${COMPILER_TOOLCHAIN}llvm-as           && echo "AS      : ${AS}"
export LD=${COMPILER_TOOLCHAIN}ld.lld            && echo "LD      : ${LD}"
export STRIP=${COMPILER_TOOLCHAIN}llvm-strip     && echo "STRIP   : ${STRIP}"
export RANLIB=${COMPILER_TOOLCHAIN}llvm-ranlib   && echo "RANLIB  : ${RANLIB}"  
export OBJDUMP=${COMPILER_TOOLCHAIN}llvm-objdump && echo "OBJDUMP : ${OBJDUMP}"
export OBJCOPY=${COMPILER_TOOLCHAIN}llvm-objcopy && echo "OBJCOPY : ${OBJCOPY}"
export NM=${COMPILER_TOOLCHAIN}llvm-nm           && echo "NM      : ${NM}"
export AR=${COMPILER_TOOLCHAIN}llvm-ar           && echo "AR      : ${AR}"

export SYSROOT=${OHOS_SDK}/native/sysroot
export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}/usr/lib/aarch64-linux-ohos
export PKG_CONFIG_PATH=${PKG_CONFIG_SYSROOT_DIR}
export PKG_CONFIG_EXECUTABLE=${PKG_CONFIG_SYSROOT_DIR}

export HNP_TOOL=${OHOS_SDK}/toolchains/hnpcli
export CMAKE=${OHOS_SDK}/native/build-tools/cmake/bin/cmake
export TOOLCHAIN_FILE=${OHOS_SDK}/native/build/cmake/ohos.toolchain.cmake

export WORK_ROOT=${PWD}
export ARCHIVE_PATH=${WORK_ROOT}/output
export COMM_DEP_PATH=${WORK_ROOT}/deps_install

export HNP_PUBLIC_PATH=${HNP_PERFIX}/data/service/hnp/
export MAKE_QUITE_PARAM=" -s "
export CONFIGURE_QUITE_PARAM=" --quiet "

export TARGET_PLATFORM=aarch64-linux-ohos
export TARGET=aarch64-linux-ohos

export CFLAGS="-fPIC -D__MUSL__=1 -D__OHOS__  -fstack-protector-strong --target=${TARGET_PLATFORM} --ld-path=${LD} --sysroot=${SYSROOT} -stdlib=libc++ "
export CXXFLAGS="${CFLAGS} "
export LD_LIBRARY_PATH=${SYSROOT}/usr/lib:${LD_LIBRARY_PATH}
export LDFLAGS="--ld-path=${LD} -Wc,--target=${TARGET_PLATFORM} --sysroot=${SYSROOT} -fuse-ld=lld "
export HOST_TYPE="--host=aarch64-linux --build=aarch64-linux"

#export NCURSES_INSTALL_HNP_PATH="${HNP_PUBLIC_PATH}/ncurses.org/ncurses_v6.4"
mkdir -p ${HNP_PUBLIC_PATH}
mkdir -p ${ARCHIVE_PATH}

chmod 777  -R  ${HNP_PUBLIC_PATH}

mkdir -p code

echo "LDFLAGS:${LDFLAGS}"
#export PKG_CONFIG_PATH="${CUSTOM_PREFIX}/lib/pkgconfig:$PKG_CONFIG_PATH"

2.2 构建脚本（build_ohos.sh）

https://github.com/kornelski/pngquant/tree/2.18.0

#clone pngquant 源码
git clone -b 2.18.0 --recursive https://github.com/kornelski/pngquant.git

有问题的脚本示例：

#!/bin/bash
export PNGQUANT_INSTALL_HNP_PATH=${HNP_PUBLIC_PATH}/pngquant.org/pngquant_2.18.0

make distclean || make clean


# 设置依赖的libpng路径(注，编译该库前确保libpng已编译)
LIBPNG_PATH=${HNP_PUBLIC_PATH}/libpng.org/libpng_1.8.0
ZLIB_PATH=${HNP_PUBLIC_PATH}/zlib.org/zlib_1.3.1


# 编译安装PNGQUANT
mkdir -p ${PNGQUANT_INSTALL_HNP_PATH}

#增加链接依赖的库
CFLAGS="${CFLAGS:-} -I${LIBPNG_PATH}/include -I${ZLIB_PATH}/include"
LDFLAGS="${LDFLAGS:-} -static -L${LIBPNG_PATH}/lib -L${ZLIB_PATH}/lib"
CXXFLAGS="${CFLAGS} "

export PKG_CONFIG_LIBDIR="${pkgconfigpath}"

export ZLIB_LIBS="-L${ZLIB_PATH}/lib -lz"
export ZLIB_CFLAGS="-I${ZLIB_PATH}/include"

./configure   --with-libpng="$LIBPNG_PATH" \
        --disable-sse \
        --extra-cflags="$CFLAGS" \
        --extra-ldflags="$LDFLAGS" \
        CC="$CC" \
        CFLAGS="$CFLAGS" \
        LDFLAGS="$LDFLAGS" \
        --prefix=${PNGQUANT_INSTALL_HNP_PATH} 

make VERBOSE=1 -j$(nproc) ZLIBFLAGS="-I${ZLIB_PATH}/include" LIBS="-L${LIBPNG_PATH}/lib -lpng -L${ZLIB_PATH}/lib ${ZLIB_PATH}/lib/libz.a -lm"
make install

# 生成鸿蒙HNP软件包
cp hnp.json ${PNGQUANT_INSTALL_HNP_PATH}/
pushd ${PNGQUANT_INSTALL_HNP_PATH}/../
    ${HNP_TOOL} pack -i ${PNGQUANT_INSTALL_HNP_PATH} -o ${ARCHIVE_PATH}/
    tar -zvcf ${ARCHIVE_PATH}/ohos_pngquant_2.18.0.tar.gz pngquant_2.18.0/
popd

报错：
ld.lld: error: --fix-cortex-a53-843419 is only supported on AArch64 targets clang-15: error: linker command failed with exit code 1 (use -v to see invocatio n) make: *** [Makefile:30: pngquant] Error 1

在这里插入图片描述
在这里插入图片描述

借助AI，推荐使用 atomcode + deepSeek

小模型也能写出大工程——AtomCode（ClaudeCode国产替代） 的介绍及使用

在这里插入图片描述
在这里插入图片描述

正确的脚本：

#!/bin/bash
export PNGQUANT_INSTALL_HNP_PATH=${HNP_PUBLIC_PATH}/pngquant.org/pngquant_2.18.0

make distclean || make clean


# 设置依赖的libpng路径(注，编译该库前确保libpng已编译)
LIBPNG_PATH=${HNP_PUBLIC_PATH}/libpng.org/libpng_1.8.0
ZLIB_PATH=${HNP_PUBLIC_PATH}/zlib.org/zlib_1.3.1


# 编译安装PNGQUANT
mkdir -p ${PNGQUANT_INSTALL_HNP_PATH}

# 从 exports.sh 继承的 LDFLAGS 包含 -Wc,--target=aarch64-linux-ohos
# 该标志仅用于编译器，链接阶段应移除，避免 clang 对目标架构判断混乱
# 重整 LDFLAGS：保留 --ld-path, --sysroot, -fuse-ld=lld，添加静态链接和库路径
LDFLAGS_CLEAN="--ld-path=${LD} --sysroot=${SYSROOT} -fuse-ld=lld -static -L${LIBPNG_PATH}/lib -L${ZLIB_PATH}/lib"

# CFLAGS 已有 --target=aarch64-linux-ohos，追加libpng/zlib头文件路径
CFLAGS="${CFLAGS:-} -I${LIBPNG_PATH}/include -I${ZLIB_PATH}/include"

# 设置 PKG_CONFIG_PATH 让 configure 通过 pkg-config 找到交叉编译的 aarch64 zlib
# 清空 PKG_CONFIG_SYSROOT_DIR 防止 pkg-config 在路径前误加 sysroot 前缀
export PKG_CONFIG_PATH="${ZLIB_PATH}/share/pkgconfig"
export PKG_CONFIG_SYSROOT_DIR=""

export ZLIB_LIBS="-L${ZLIB_PATH}/lib -lz"
export ZLIB_CFLAGS="-I${ZLIB_PATH}/include"

./configure   --with-libpng="$LIBPNG_PATH" \
        --disable-sse \
        --extra-cflags="$CFLAGS" \
        --extra-ldflags="$LDFLAGS_CLEAN" \
        CC="$CC" \
        CFLAGS="$CFLAGS" \
        LDFLAGS="$LDFLAGS_CLEAN" \
        --prefix=${PNGQUANT_INSTALL_HNP_PATH}

# make 时覆盖 LDFLAGS，确保使用正确的交叉编译静态库而非宿主机的 x86_64 库
make VERBOSE=1 -j$(nproc) 
make install

# 生成鸿蒙HNP软件包
cp hnp.json ${PNGQUANT_INSTALL_HNP_PATH}/
pushd ${PNGQUANT_INSTALL_HNP_PATH}/../
    ${HNP_TOOL} pack -i ${PNGQUANT_INSTALL_HNP_PATH} -o ${ARCHIVE_PATH}/
    tar -zvcf ${ARCHIVE_PATH}/ohos_pngquant_2.18.0.tar.gz pngquant_2.18.0/
popd

在这里插入图片描述
构建产物的位置：
在这里插入图片描述

2.3 x86_64上的鸿蒙PC容器中验证

参考博文：低成本搭建鸿蒙PC运行环境：基于 Docker 的 x86_64 服务器

cd /data/service/hnp/pngquant.org/pngquant_2.18.0/
#拷贝进鸿蒙PC容器
docker cp pngquant  ohos:root
#进入ohos pc容器
docker exec -it ohos sh
#验证测试命令行应用
cd /root
#验证可执行文件
./pngquant --version

在这里插入图片描述

方案二 使用lycium_plusplus编译框架

lycium_plusplus是什么？

lycium_plusplus 是一个专为 OpenHarmony 及鸿蒙 PC 环境设计的 C/C++ 编译框架，主要用于简化三方库的编译、构建和打包流程。它基于 lycium 编译框架进行增强，支持一键构建依赖关系树，并提供对多版本库的编译能力，尤其适用于在鸿蒙 PC 系统上移植和编译命令行工具或库文件（如 tree、x264 等）。

主要特性：

一键构建依赖：自动解析并构建项目依赖关系，无需手动配置复杂编译流程。
支持外部仓适配：通过 outerrepo/module.json 配置外部代码仓库（如 Git 仓库），实现独立发布和动态集成。

生成 HNP 包：支持生成 .hnp 格式的鸿蒙系统打包文件，便于作为组件与应用一同安装。
跨平台编译：支持在 Linux（如 Ubuntu）、Windows、macOS 上进行交叉编译，生成适用于鸿蒙 PC（ARM64 架构）的可执行程序。
本机编译支持：鸿蒙 PC 系统升级至 6.0.0.115 或以上版本后，可直接在设备上使用 build_local.sh 脚本进行本机编译，无需交叉编译环境。

下载lycium_plusplus：

git clone https://gitcode.com/OpenHarmonyPCDeveloper/lycium_plusplus.git

在这里插入图片描述
使用举例：

cd lyium
./build.sh tree

获取编译产物

可在lycium/usr/tree/下获取对应架构下的二进制产物
可在lycium/output/下获取对应架构下的归档产物

结果验证

构建成功后，可在以下路径找到产物：

可执行程序：usr/tree/arm64-v8a/bin/tree

HNP 打包文件：output/arm64-v8a/tree.hnp

外部适配仓参与构建：

本项目新增目录external_deps用于临时存放外部仓，外部仓信息存放在external_deps/module.json中
该文件中包含的关键要素如下：

"module" : [
{
"name" : "tree",
"branch" : "ohos_2.2.1",
"version" : "2.2.1",
"type" : "git",
"url" : "https://gitcode.com/OpenHarmonyPCDeveloper/ohos_tree.git"
}
]

使用此方式编译pngquant:

详见博文：HarmonyOS / OpenHarmony 鸿蒙PC平台三方库移植：使用 Lycium 移植 pngquant 的实践总结

在这里插入图片描述

方案三 使用vcpkg构建鸿蒙三方库

参考博文：使用 vcpkg 为鸿蒙（HarmonyOS / OHOS）下载与安装三方库实践指南

使用 vcpkg 将 pngquant 命令行移植到鸿蒙 PC

vcpkg (针对 C++ 库的包管理)：虽然它最初是c/c++的包管理器，但它的 triplet 机制（如当前的 arm64-ohos）本质上也是一种轻量级的交叉编译配置框架。

vcpkg鸿蒙仓地址： https://gitcode.com/OpenHarmonyPCDeveloper/ohos_vcpkg

使用环境：linux_x86_64

git clone https://gitcode.com/OpenHarmonyPCDeveloper/ohos_vcpkg.git

在这里插入图片描述
使用举例：

# 1.设置OHOS_SDK_ROOT环境变量
export OHOS_SDK_ROOT=/root/ohos-sdk/linux/
# 2.开始使用
cd ohos_vcpkg
# 开始构建
vcpkg install --triplet arm64-ohos libpng libjpeg-turbo
#或者
vcpkg install libpng:arm64-ohos libjpeg-turbo:arm64-ohos

方案四 使用AI自动化编译框架build_in_harmonyos框架

参考博文：HarmonyOS / OpenHarmony 鸿蒙PC平台三方库移植：AI自动化编译框架build_in_harmonyos介绍及使用

当前该项目仅支持在鸿蒙PC上使用（注意该限制条件）。

该项目通过AI技术实现"编一次、记一次、下次更快"的流水线作业，将补丁、错误对策等经验转化为可复用的知识图谱。主要包含两个仓库：build_in_harmonyos（编译框架和知识档案）和cmd-pkgs（预编译包分发）。用户可通过自然语言指令让AI Agent完成软件编译全过程，目前已支持394个软件沉淀。

build_in_harmonyos 的亮点不在于「又多了一个构建脚本，除了前面介绍过的lycim和vcpkg等框架」，而在于三件事同时成立：流程一体化、路径与打包Engineering、错误与经验资产化。借助AI的能力，让三方库软件移植变得如此简单！即便是小白用户也能通过简单的语言描述完成移植，凸显在整个 OpenHarmony PC 生态里的价值。

项目的思路和方法非常不错，值得借鉴！相当于它有了自动进化的能力，用的人越多它越强，贡献越大！

该项目确实非常有启发性。它最核心的魅力在于将 AI 的推理能力与结构化的工程知识（知识图谱） 结合，实现了从“人工搬砖”到“机器自我进化”的跨越。

使用方式：一句话完成三方库或命令行软件移植。
在这里插入图片描述
在这里插入图片描述

参考链接

http://www.171host.com/147181.html
https://gitcode.com/OpenHarmonyPCDeveloper/build

# harmonyos # 华为 # AI
Logo
人工智能6S服务平台

作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。

更多推荐

vLLM适配昇腾NPU：DeepSeek-V3 PD分离部署完整流程

做过大模型推理优化的朋友都知道,Prefill和Decode这两个阶段的性质完全不同:Prefill阶段就像是读完整本书做笔记——需要把用户输入的完整prompt编码成隐藏状态,同时生成KV Cache。这个过程计算量大,吃算力。Decode阶段更像是一个字一个字往外蹦——每次只生成一个token,一直重复到结束。这个过程主要瓶颈在显存带宽,属于典型的访存密集型任务。两个阶段混在一起跑,就会出现资

avatar 人工智能6S服务平台

昇腾NPU上编译Apex：从踩坑到搞定

我们用的是MindIE的openEuler镜像，先装基础依赖：暂时无法在飞书文档外展示此内容然后就可以开始执行编译：暂时无法在飞书文档外展示此内容Apex编译看似简单,实则暗藏许多细节。本文通过真实案例,深入剖析了从网络代理到系统库路径的各个环节。Docker守护进程代理配置容易漏lib和lib64路径差异编译脚本会覆盖手动修改希望大家可以学习一些经验教训，对于大模型训练来说，Apex基本是必备工

avatar 人工智能6S服务平台

昇腾NPU上编译Apex：从踩坑到搞定

更新系统# 编译工具# Python开发包# torchApex编译看似简单,实则暗藏许多细节。本文通过真实案例,深入剖析了从网络代理到系统库路径的各个环节。Docker守护进程代理配置容易漏lib和lib64路径差异编译脚本会覆盖手动修改希望大家可以学习一些经验教训，对于大模型训练来说，Apex基本是必备工具。昇腾适配版虽然有些小坑，但整体可用性还不错，注明：昇腾PAE案例库对本文写作亦有帮助。

avatar 人工智能6S服务平台