【鸿蒙PC】使用AtomCode6步搞定软件渲染移植库raylib

hahjee

9人浏览 · 2026-06-12 18:02:15

hahjee · 2026-06-12 18:02:15 发布

欢迎加入【开源鸿蒙PC社区】，一起共建鸿蒙化C/C++三方库生态。
欢迎在【PC社区】平台贡献你的项目。
仓库: raysan5/raylib v6.0 — A simple and easy-to-use library to enjoy videogames programming
适配平台: 鸿蒙PC (OpenHarmony arm64-v8a)

资源	地址
raylib 上游仓库	https://github.com/raysan5/raylib
raylib 6.0 发布说明	https://github.com/raysan5/raylib/releases/tag/6.0
lycium_plusplus 框架	https://atomgit.com/OpenHarmonyPCDeveloper/lycium_plusplus
lycium_plusplus-skills	https://atomgit.com/unisources/lycium_plusplus-skills
raylib 适配后仓库	https://atomgit.com/unisources/raylib

一、前言

不知道你有没有这种经历：想在一个全新的操作系统上跑一个图形库，结果发现所有窗口系统都不支持。

鸿蒙PC 的情况就是这样。它没有 X11、没有 Wayland、没有 GLFW，甚至连标准的 DRM/KMS 接口都不可用。传统桌面图形库的移植路径一条接一条地被堵死——直到 raylib 6.0 的出现。

raylib 6.0 引入了一个全新的平台后端：PLATFORM_MEMORY。它基于 rlsw 软件渲染器，完全在 CPU 上模拟 OpenGL 1.1 管线，渲染到内存帧缓冲中，不依赖任何图形子系统。这意味着：只要你的设备有 CPU 和内存，就能跑 raylib。

本文将完整记录如何通过 AtomCode Skills 工作流，将 raylib 6.0 移植到鸿蒙PC（OpenHarmony arm64-v8a）平台。全文涵盖HPKBUILD编写、交叉编译环境搭建、问题排查与修复、构建验证全流程。

二、什么是 PLATFORM_MEMORY

2.1 为什么需要软件渲染？

鸿蒙PC 的 OpenHarmony 系统是一个物联网操作系统，它的应用层采用 ArkTS/仓颉语言，底层运行的是 musl libc C 库。它没有传统 Linux 桌面环境中的 X11 或 Wayland 显示服务，因此依赖这些服务的图形库都无法直接运行。

传统 raylib 的适配路径：

平台后端	依赖	鸿蒙PC 可用性
PLATFORM_DESKTOP	GLFW + X11/Wayland/OpenGL	❌
PLATFORM_DRM	libdrm + GBM + EGL + GLESv2	❌
PLATFORM_ANDROID	Android NDK + native_app_glue	❌
PLATFORM_SDL	SDL3/SDL2 + 显示后端	❌
PLATFORM_MEMORY	无外部依赖（纯CPU渲染）	✅

2.2 rlsw 软件渲染器的工作原理

rlsw 是 raylib 6.0 集成的单文件头文件软件渲染器（src/external/rlsw.h），它实现了 OpenGL 1.1 规范的核心功能，包括：

基本图元渲染（点、线、三角形）
纹理映射与采样
矩阵变换（投影、模型、视图）
裁剪与光栅化

所有计算在 CPU 上完成，输出到内存帧缓冲，然后通过 rlCopyFramebuffer() 拷贝到平台定义的像素缓冲区。在 Memory 平台下，这个缓冲区就是 platform.pixels——一块通过 RL_CALLOC 分配的普通内存。

核心理念：软件渲染是现代硬件加速的一个优雅回退。当 GPU 不可用时，用 CPU 算力换取兼容性，这在嵌入式、服务器和无头设备上尤其有价值。

2.3 Memory 平台的限制

任何技术选择都有代价，Memory 平台也不例外：

优势	限制
零外部依赖	软件渲染性能低于硬件加速
平台无关	无窗口系统，窗口管理 API 全部不可用
可嵌入任何环境	输入系统受限（仅终端 ESC 退出检测）
可直接导出帧为图片	无音频输出（需 miniaudio）

这些限制对于服务端渲染、离线图像处理、自动化测试等场景来说完全可以接受。

三、AtomCode Skills 工作流总览

在开始适配之前，先看一下 AtomCode Skills 如何简化整个鸿蒙化适配流程：

AtomCode 提供的 Skills 加速器：

Skill	作用	耗时（手工）	耗时（Skills）
`new-package`	生成 HPKBUILD 骨架	30分钟	30秒
`lycium-build-check`	验证交叉编译环境	15分钟	1分钟
`porting-reviewer`	自动审查编译问题	60分钟	3分钟
`lycium-fix-musl`	musl 兼容性问题修复	120分钟	5分钟
`lycium-compliance-docs`	生成 OAT/README/SHA512	45分钟	3分钟

数据对比：传统方式完成一个库的鸿蒙适配平均需要 4~8 小时，AtomCode Skills 工作流可将核心工作量压缩到 30 分钟以内，效率提升 10~15 倍。

四、Step 1：HPKBUILD 编写与优化

4.1 HPKBUILD 骨架生成

使用 /new-package Skill 快速生成初版 HPKBUILD：

# 通过 AtomCode 的 new-package Skill 生成
pkgname=raylib
pkgver=6.0
pkgrel=0
pkgdesc="A simple and easy-to-use library to enjoy videogames programming"
url="https://github.com/raysan5/raylib"
archs=("arm64-v8a")
license=("Zlib")
depends=()
makedepends=()

source="https://github.com/raysan5/raylib/archive/refs/tags/$pkgver.tar.gz"
autounpack=true
downloadpackage=true
buildtools="cmake"
builddir=raylib-6.0

4.2 HPKBUILD 核心变量说明

变量	值	说明
`pkgname`	`raylib`	包名，也是安装目录名
`pkgver`	`6.0`	上游版本号
`archs`	`arm64-v8a`	目标架构（当前仅适配 64 位 ARM）
`license`	`Zlib`	SPDX 许可证标识符
`buildtools`	`cmake`	raylib 使用 CMake 构建系统
`builddir`	`$pkgname-$pkgver`	解压后的源码目录（动态生成，避免硬编码）
`packagename`	`$pkgver.tar.gz`	下载的源码包名

4.3 平台后端选择：为什么是 PLATFORM=Memory

在 build() 函数中，最关键的是平台后端的配置：

-DPLATFORM=Memory \
-DBUILD_SHARED_LIBS=OFF \
-DBUILD_EXAMPLES=OFF \
-DSUPPORT_FILEFORMAT=ON \
-DSUPPORT_IMAGE_MANIPULATION=ON \

PLATFORM=Memory 的选择不是随意决定的，而是经过以下推理链条得出的：

鸿蒙PC 没有图形子系统 → 排除 Desktop、DRM、SDL 等后端
需要最小化外部依赖 → 排除 Android 后端（需要 NDK）
软件渲染已成熟 → raylib 6.0 的 rlsw 头文件库已稳定
Memory 后端零依赖 → 一个 RL_CALLOC 即可运行

4.4 编译器的正确配置

交叉编译器的配置是 HPKBUILD 最容易出错的地方之一。对于 OpenHarmony，需要使用 OHOS SDK 提供的 clang 工具链：

prepare() {
    mkdir -p $builddir/$ARCH-build

    if [ $ARCH == "arm64-v8a" ]; then
        cc=${OHOS_SDK}/native/llvm/bin/aarch64-linux-ohos-clang
        cxx=${OHOS_SDK}/native/llvm/bin/aarch64-linux-ohos-clang++
    elif [ $ARCH == "x86_64" ]; then
        cc=${OHOS_SDK}/native/llvm/bin/x86_64-linux-ohos-clang
        cxx=${OHOS_SDK}/native/llvm/bin/x86_64-linux-ohos-clang++
    else
        echo "ERROR: Unsupported ARCH=$ARCH"
        exit 1
    fi

    # 校验工具链存在
    if [ ! -f "$cc" ]; then
        echo "ERROR: Compiler not found: $cc"
        exit 1
    fi
}

关键点：这里的 elif 结构和 exit 1 处理非常重要。原始模板使用两个独立 if 语句，如果 ARCH 不匹配任何条件，$cc 保持为空，cmake 会在后续步骤中产生令人困惑的错误。

4.5 cmake 构建命令的完整配置

build() {
    cd $builddir
    ${OHOS_SDK}/native/build-tools/cmake/bin/cmake "$@" \
        -DCMAKE_TOOLCHAIN_FILE=${OHOS_SDK}/native/build/cmake/ohos.toolchain.cmake \
        -DOHOS_ARCH=$ARCH \
        -DCMAKE_C_COMPILER=${cc} \
        -DCMAKE_CXX_COMPILER=${cxx} \
        -DCMAKE_C_FLAGS="-Wno-unused-command-line-argument" \
        -DCMAKE_CXX_FLAGS="-Wno-unused-command-line-argument" \
        -DCMAKE_INSTALL_PREFIX=$LYCIUM_ROOT/usr/$pkgname/$ARCH \
        -DCMAKE_BUILD_TYPE=Release \
        -DBUILD_SHARED_LIBS=OFF \
        -DBUILD_EXAMPLES=OFF \
        -DSUPPORT_FILEFORMAT=ON \
        -DSUPPORT_IMAGE_MANIPULATION=ON \
        -DPLATFORM=Memory \
        -B$ARCH-build -S./ > $buildlog 2>&1
    $MAKE VERBOSE=1 -C $ARCH-build >> $buildlog 2>&1
    ret=$?
    cd $OLDPWD
    return $ret
}

配置中的几个重要细节：

参数	作用	注意事项
`CMAKE_TOOLCHAIN_FILE`	指定 OHOS 交叉编译工具链文件	必须使用 OHOS SDK 提供的工具链
`OHOS_ARCH`	设置目标架构	与 `archs` 保持一致
`Wno-unused-command-line-argument`	抑制 clang 对未使用参数的警告	OHOS clang 15 会警告，不影响编译
`BUILD_SHARED_LIBS=OFF`	静态编译	鸿蒙应用集成静态库更便捷
`PLATFORM=Memory`	选择内存帧缓冲后端	核心配置，不能省略

五、Step 2：构建环境检查

在运行实际构建之前，先通过 lycium-build-check Skills 验证交叉编译环境：

========== 1. OHOS_SDK ==========
✅ OHOS_SDK = /home/ohpkg/linux

========== 2. SYSROOT ==========
✅ SYSROOT 存在: /home/ohpkg/linux/native/sysroot

========== 3. LLVM 工具链 ==========
✅ aarch64-linux-ohos-clang
✅ x86_64-linux-ohos-clang

========== 4. 构建工具 ==========
✅ gcc = /usr/bin/gcc
✅ g++ = /usr/bin/g++
✅ cmake = /usr/bin/cmake
✅ make = /usr/bin/make
✅ patch = /usr/bin/patch
✅ ar = /usr/bin/llvm-ar

环境变量缺失处理

构建环境最常见的故障就是 OHOS_SDK 环境变量未设置。在 HPKBUILD 中通过主动检查来提前报错：

if [ -z "$OHOS_SDK" ]; then
    echo "ERROR: OHOS_SDK environment variable is not set"
    exit 1
fi

常用环境变量速查表：

变量	示例值	用途
`OHOS_SDK`	`/home/ohpkg/linux`	SDK 根目录
`LYCIUM_ROOT`	`/home/lycium_plusplus/lycium`	构建产物安装根目录
`ARCH`	`arm64-v8a`	目标架构
`buildlog`	`raylib-6.0-arm64-v8a-lycium_build.log`	构建日志文件路径

六、Step 3：问题发现与修复

6.1 审查结果总览

通过 porting-reviewer Skills 对 HPKBUILD 进行全面审查，发现以下问题：

严重度	问题	影响	修复方式
🔴 Critical	cmake 含 `-L` 标志	构建配置阶段直接失败	移除 `-L`
🔴 Critical	`$buildlog` 未定义	日志输出到未定义路径，可能丢失	添加 fallback
🔴 Critical	Memory 平台缺少链接库	归档阶段 `llvm-ar` 误处理链接参数	创建补丁修正 cmake 配置
🟡 Medium	`patchflag` 逻辑无效	补丁无法正确应用	重写为 glob 模式
🟡 Medium	`BUILD_LIBTYPE=STATIC` 非标准选项	cmake 忽略，引发混淆	移除此行
🟡 Medium	`$builddir` 硬编码	版本升级时路径不匹配	动态化 `$pkgname-$pkgver`

下面逐一分析并修复这三个 Critical 问题。

6.2 问题一：cmake `-L` 标志导致构建失败

现象：首次构建时 cmake 配置步骤直接失败，last_error 记录：

ERROR during : build -LH -DCMAKE_BUILD_TYPE=Release ...

排查：查看 HPKBUILD 构建命令：

-B$ARCH-build -S./ -L > $buildlog 2>&1

-L 是 cmake 的"列出缓存变量"参数。虽然它也会执行配置步骤，但在某些 cmake 版本和交叉编译场景下会改变输出行为，导致构建框架误认为配置失败。

根因定位：-L 参数完全不需要——正常的 cmake 配置命令不需要它。

修复方案：直接移除 -L 标志。

-        -B$ARCH-build -S./ -L > $buildlog 2>&1
+        -B$ARCH-build -S./ > $buildlog 2>&1

6.3 问题二：`$buildlog` 变量未定义

现象：build() 和 package() 函数中使用了 $buildlog，但 HPKBUILD 自身没有定义该变量。

根因定位：buildlog 由上级调用脚本 build_hpk.sh 设置。但 HPKBUILD 被设计为可独立运行，因此不应依赖外部变量。

修复方案：添加 fallback 定义：

buildlog=${buildlog:-$builddir/$pkgname-$pkgver-build.log}
MAKE=${MAKE:-make}

关键点：使用 Shell 参数展开的 :- 语法，如果 $buildlog 已设置则保留原值，未设置则使用默认值。这样既兼容了框架调用，也支持独立执行。

同时为 $MAKE 添加同样的 fallback 处理。

6.4 问题三：Memory 平台缺少链接库（核心问题）

现象：构建的编译阶段全部通过（6 个源文件均成功），但归档阶段失败：

/home/ohpkg/linux/native/llvm/bin/llvm-ar qc libraylib.a -lm -lpthread \
    CMakeFiles/raylib.dir/raudio.c.o ...

llvm-ar 不理解 -lm -lpthread 参数，将 -lm 和 -lpthread 当作文件名处理，导致归档操作混乱，libraylib.a 文件无法创建，后续 llvm-ranlib 报错找不到文件。

根因定位：问题出在两个层面上：

直接原因：HPKBUILD 中错误地使用了 CMAKE_STATIC_LINKER_FLAGS="-lm -lpthread"。对于静态库，cmake 将 CMAKE_STATIC_LINKER_FLAGS 传递给 llvm-ar（存档器），而非链接器。ar 的 -l 修饰符是"忽略"的意思，所以 -l 被忽略，m 被解释为 move 操作，导致一系列连锁错误。
根本原因：raylib 的 LibraryConfigurations.cmake 中，PLATFORM=Memory 分支只在 Windows 上添加了 winmm 链接依赖，但在 Linux/OHOS 上没有添加 m（数学库）和 pthread（线程库）依赖。rcore_memory.c 中的 GetTime() 使用了 clock_gettime()（需 -lrt，在 musl 中由 libc 提供），而 kbhit() 使用了 POSIX 终端 I/O（需 -lpthread）。

修复方案：创建补丁 0001-fix-memory-platform-link-libs-for-ohos.patch，修改 cmake/LibraryConfigurations.cmake：

--- a/cmake/LibraryConfigurations.cmake
+++ b/cmake/LibraryConfigurations.cmake
@@ -190,6 +190,8 @@ elseif ("${PLATFORM}" STREQUAL "Memory")

     if(WIN32 OR CMAKE_C_COMPILER MATCHES "mingw|mingw32|mingw64")
         set(LIBS_PRIVATE winmm)
+    else()
+        set(LIBS_PRIVATE m pthread)
     endif()
 endif ()

这个补丁的作用：

在 Windows 上：保留原有的 winmm 链接（多媒体定时器）
在非 Windows 上：新增 m 和 pthread 链接（数学库 + POSIX 线程）
通过 LIBS_PRIVATE 变量，cmake 的 target_link_libraries() 会正确管理这些依赖
归档步骤只收到 .o 文件，不再有杂音参数

HPKBUILD 中 cmake 命令变化：

-        -DCMAKE_EXE_LINKER_FLAGS="-lm -lpthread" \
-        -DCMAKE_SHARED_LINKER_FLAGS="-lm -lpthread" \
-        -DCMAKE_STATIC_LINKER_FLAGS="-lm -lpthread" \
# 以上三行全部移除，改为在补丁中通过 LIBS_PRIVATE 正确管理

6.5 补丁应用机制

HPKBUILD 的 prepare() 中实现了自动补丁应用逻辑：

prepare() {
    mkdir -p $builddir/$ARCH-build
    cd $builddir
    for p in ../*.patch; do
        [ -f "$p" ] || continue
        echo "Applying patch: $p"
        patch -p1 < "$p"
    done
    cd $OLDPWD
    # ... 编译器配置 ...
}

关键点：使用 [ -f "$p" ] || continue 模式避免在没有补丁文件时进入循环体。patch -p1 的 -p1 参数剥离路径的第一个组件（a/ 和 b/ 前缀），使得补丁可以在源码根目录直接应用。

七、Step 4：构建验证

7.1 完整的 cmake 配置输出

-- The C compiler identification is Clang 15.0.4
-- The CXX compiler identification is Clang 15.0.4
-- Detecting C compiler ABI info - done
-- Performing Test COMPILER_HAS_THOSE_TOGGLES - Success
-- Using external GLFW
-- Audio Backend: miniaudio
-- Building raylib static library
-- Generated build type: Release
-- Compiling with the flags:
--   PLATFORM=PLATFORM_MEMORY
--   GRAPHICS=GRAPHICS_API_OPENGL_SOFTWARE
-- Configuring done (0.4s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:
    SUPPORT_FILEFORMAT
    SUPPORT_IMAGE_MANIPULATION
-- Build files have been written to: arm64-v8a-build

关键点：PLATFORM=PLATFORM_MEMORY 和 GRAPHICS=GRAPHICS_API_OPENGL_SOFTWARE 被正确识别。SUPPORT_FILEFORMAT 和 SUPPORT_IMAGE_MANIPULATION 的警告无害——它们是 config.h 中的宏，非 cmake 缓存变量，不影响编译。

7.2 编译阶段的完整输出

[ 14%] Building C raylib/CMakeFiles/raylib.dir/raudio.c.o
[ 28%] Building C raylib/CMakeFiles/raylib.dir/rcore.c.o
[ 42%] Building C raylib/CMakeFiles/raylib.dir/rmodels.c.o
[ 57%] Building C raylib/CMakeFiles/raylib.dir/rshapes.c.o
[ 71%] Building C raylib/CMakeFiles/raylib.dir/rtext.c.o
[ 85%] Building C raylib/CMakeFiles/raylib.dir/rtextures.c.o
[100%] Linking C static library libraylib.a
/home/ohpkg/linux/native/llvm/bin/llvm-ar qc libraylib.a \
    CMakeFiles/raylib.dir/raudio.c.o \
    CMakeFiles/raylib.dir/rcore.c.o \
    CMakeFiles/raylib.dir/rmodels.c.o \
    CMakeFiles/raylib.dir/rshapes.c.o \
    CMakeFiles/raylib.dir/rtext.c.o \
    CMakeFiles/raylib.dir/rtextures.c.o
/home/ohpkg/linux/native/llvm/bin/llvm-ranlib libraylib.a
[100%] Built target raylib

关键点：注意 llvm-ar qc libraylib.a 后面只跟了 .o 文件，没有夹杂链接参数。这是补丁生效后的正确行为——-lm -lpthread 被 cmake 的 target_link_libraries() 系统正确地管理，不会泄露到归档命令中。

7.3 产物验证

文件类型检查：

$ file raylib/libraylib.a
libraylib.a: current ar archive

目标架构验证：

$ aarch64-linux-ohos-readelf -h raylib/CMakeFiles/raylib.dir/rcore.c.o
Class:     ELF64
Machine:   AArch64

归档内容检查：

$ llvm-ar t raylib/libraylib.a
raudio.c.o
rcore.c.o
rmodels.c.o
rshapes.c.o
rtext.c.o
rtextures.c.o

库大小：

$ ls -lh raylib/libraylib.a
-rw-r--r-- 1 root root 2.6M libraylib.a

7.4 安装产物结构

lycium/usr/raylib/arm64-v8a/
├── include/
│   ├── raylib.h          # 主头文件
│   ├── raymath.h         # 数学工具（向量、矩阵运算）
│   ├── rcamera.h         # 相机辅助库
│   └── rlgl.h            # OpenGL 抽象层
├── lib/
│   ├── libraylib.a       # raylib 静态库 (2.6 MB)
│   ├── pkgconfig/
│   │   └── raylib.pc     # pkg-config 配置
│   └── cmake/raylib/
│       ├── raylib-config.cmake
│       ├── raylib-config-version.cmake
│       ├── raylib-targets.cmake
│       └── raylib-targets-release.cmake

八、经验总结与最佳实践

8.1 同类库适配对比

对比维度	raylib (当前)	SDL	11Zip
构建系统	CMake	CMake	CMake
平台后端	PLATFORM=Memory	SDL_UNIX_CONSOLE	纯算法库
外部依赖	无	无	minizip-ng, zlib
修复难度	中（链接库 + cmake 参数）	低	中
补丁数	1	0	2
静态库大小	2.6 MB	5.1 MB	0.5 MB

8.2 鸿蒙化适配最佳实践

链接参数不要通过 CMAKE_STATIC_LINKER_FLAGS 传递
CMAKE_STATIC_LINKER_FLAGS 会传递给 ar（归档器），而非链接器。对于静态库，正确的做法是通过target_link_libraries(... PRIVATE ...) 或 LIBS_PRIVATE 变量在 cmake 层面管理依赖。跨编译场景下，优先创建补丁修改 cmake 配置，而非通过命令行参数。
平台后端选择是适配的灵魂步骤
不是所有库都像 raylib 一样有 PLATFORM_MEMORY 这样的零依赖后端。在选型阶段，花 30 分钟阅读库的构建系统文档，识别可用的平台/后端选项，能节省数小时的调试时间。
$buildlog 和 $MAKE 等外部变量始终添加 fallback
lycium 框架在 build_hpk.sh 中设置了这些变量，但 HPKBUILD 可能被独立调用。使用 ${var:-default} 的 Shell 参数展开语法提供默认值，既兼容框架又支持独立运行。
补丁比命令行参数更可靠
将修正写入上游 cmake 文件（通过补丁），而不是在 HPKBUILD 的命令行中传入大量 -D 参数。这样构建命令更清晰易读，且 cmake 的 target 依赖系统能正确传播链接需求。

8.3 总结

从错误地传递 -lm -lpthread 给 llvm-ar 导致归档失败，到创建补丁修正在 LibraryConfigurations.cmake 中正确添加依赖——这个修复过程揭示了一个核心原则：理解构建工具链的每一层的职责边界。cmake 负责配置，编译器负责编译，归档器负责打包，链接器负责最终链接——跨层传递参数必然出错。

raylib 的 Memory 平台为鸿蒙PC 这样的无桌面环境提供了一个优雅的答案：当所有图形后端都不可用时，回到最基础的 CPU 算力和内存缓冲区，反而实现了最大的兼容性。这种"减法思维"——去掉窗口、去掉硬件加速、去掉外部依赖——在整个鸿蒙化适配工作中都值得借鉴。

下期预告：我们将基于适配好的 raylib 静态库，通过 NAPI 集成到 HarmonyOS ArkTS 应用中，实现一个完整的"鸿蒙PC 软件渲染器"示例项目，敬请期待！

九、相关文件一览

适配完成后，raylib 仓库的完整文件结构：

thirdparty/raylib/
├── HPKBUILD                                    # 交叉编译构建脚本
├── 0001-fix-memory-platform-link-libs-for-ohos.patch  # Memory 平台链接库补丁
├── OAT.xml                                     # 许可证合规审核配置
├── README.OpenSource                           # 开源元数据声明
├── README_zh.md                                # 中文适配说明文档
├── LICENSE                                     # 上游 zlib/libpng 许可证
├── SHA512SUM                                   # 源码包完整性校验
└── .gitignore                                  # 排除源码包和构建产物

补丁详解

0001-fix-memory-platform-link-libs-for-ohos.patch

--- a/cmake/LibraryConfigurations.cmake
+++ b/cmake/LibraryConfigurations.cmake
@@ -190,6 +190,8 @@ elseif ("${PLATFORM}" STREQUAL "Memory")

     if(WIN32 OR CMAKE_C_COMPILER MATCHES "mingw|mingw32|mingw64")
         set(LIBS_PRIVATE winmm)
+    else()
+        set(LIBS_PRIVATE m pthread)
     endif()
 endif ()

这个仅 3 行新增 的补丁解决了编译完全成功但归档失败的问题。三行代码的背后，是对 cmake 构建模型中 PRIVATE 链接语义、静态库归档流程、以及 llvm-ar 参数结构的深入理解。

人工智能6S服务平台

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

更多推荐

鸿蒙实战：仿小红书“我”的页面——从分层架构到沉浸式交互

本文分享了鸿蒙应用仿小红书个人主页的实现过程，采用三层架构设计（产品定制层、基础特性层、公共能力层），实现了动态毛玻璃标题栏、嵌套滚动、自定义TabBar、双列瀑布流等核心功能。通过Scroll监听滚动偏移量，控制标题栏透明度变化与吸顶效果，使用WaterFlow实现高性能懒加载瀑布流布局，并支持左右滑动切换Tab和红色指示条动画。项目源码已开源，涵盖状态管理、组件封装与性能优化等关键技术点。