欢迎加入【开源鸿蒙PC社区】一起共建鸿蒙化C/C三方库生态。欢迎在【PC社区】平台贡献你的项目。仓库: open-mpi/hwloc v2.14.0 — Portable hardware topology detection library适配平台: 鸿蒙PC资源地址hwloc 上游仓库https://github.com/open-mpi/hwlochwloc 官方文档https://www.open-mpi.org/projects/hwloc/doc/lycium_plusplus 框架https://atomgit.com/OpenHarmonyPCDeveloper/lycium_pluspluslycium_plusplus-skillshttps://atomgit.com/unisources/lycium_plusplus-skillshwloc 适配后仓库https://atomgit.com/unisources/hwloc一、前言不知道你有没有这种经历一个 Linux 上编译如丝般顺滑的 C 库换到嵌入式平台后就处处碰壁——今天缺个工具链明天不认操作系统名。为了编译一个跨平台库你花了半天装依赖、改 Makefile、调试链接错误最后发现最根本的问题是 autoconf 的那一套工具链根本不认识你的目标平台。hwlocHardware Locality就让我经历了这样一次「水土不服」。它是一个成熟的硬件拓扑检测库在 HPC高性能计算领域应用广泛能够探测 CPU 核心数、缓存层级、NUMA 节点、甚至 GPU 在系统总线上的物理位置。在 Linux 服务器上它可以帮你做进程资源绑定和性能优化。而我们的目标是把这套能力带到鸿蒙PC。结果一上来就遇到了一个经典问题configure: OS ‘ohos’ not recognized。OpenHarmony 这个操作系统名字autoconf 不认识。这个错误信息背后的机制涉及到 autoconf 工具链中一个叫做config.sub的关键文件——它维护了一份已知操作系统的白名单。解决方案其实很简单——在名单里加上 ohos——但前提是你得理解这个文件在构建流程中的位置。更具体地说hwloc 使用 autoconf/automake/libtool 构建系统这意味着它的 GitHub tarball 甚至不包含可直接运行的configure脚本。你需要先安装 libtool运行autogen.sh引导构建修补config/config.sub然后才能进入常规的configure make make install流程。每一步都藏着坑。本文将完整记录如何通过 AtomCode Skills 工作流将 hwloc 2.14.0 移植到鸿蒙PCOpenHarmony arm64-v8a平台。全文涵盖 autoconf 库的 HPKBUILD 编写、config.sub 的修补原理与实操、构建验证全流程。二、AtomCode Skills 工作流总览在正式开始适配之前先看一下 AtomCode Skills 如何将 hwloc 的 autoconf 适配流程结构化Skills工作流new-packageHPKBUILD生成lycium-build-check环境检查发现 libtool 缺失安装 libtoolautogen.sh 引导构建config.sub 不识别 ohossed 修补 config.subconfigure / make / installlycium-compliance-docs合规文档生成✅ 适配完成AtomCode 提供的核心技能加速器Skill作用传统方式耗时Skills 耗时new-package生成 autoconf 类 HPKBUILD 骨架30 分钟30 秒lycium-build-check验证交叉编译环境含 libtool 检测15 分钟1 分钟lycium-fix-muslmusl 兼容性问题修复120 分钟5 分钟lycium-compliance-docs生成 OAT / README / SHA51245 分钟3 分钟数据对比传统方式完成一个 autoconf 库的鸿蒙适配平均耗时 6~10 小时主要时间花在 config.sub 排查和工具链缺失定位上AtomCode Skills 工作流可将核心工作量压缩到 40 分钟以内。四、Step 1HPKBUILD 编写4.1 前置条件工具版本说明OHOS SDKlatest/home/ohpkg/linuxlycium_pluspluslatest交叉编译框架libtool2.4.7hwloc 依赖 autoconf/automake/libtool4.2 HPKBUILD 骨架生成hwloc 使用 autoconf/automake 构建与 CMake 库不同它的 GitHub tarball 不包含生成的configure脚本——只包含configure.ac。因此prepare()中需要先运行autogen.sh来引导构建系统。pkgnamehwlocpkgver2.14.0pkgrel0pkgdescHardware Locality (hwloc) — Portable hardware topology detection libraryurlhttps://www.open-mpi.org/projects/hwloc/archs(arm64-v8a)license(BSD-3-Clause)depends()makedepends()sourcehttps://github.com/open-mpi/hwloc/archive/refs/tags/hwloc-$pkgver.tar.gzautounpacktruebuildtoolsautoconfbuilddirhwloc-hwloc-$pkgver关键点buildtoolsautoconf告诉 lycium 框架使用 autoconf 构建系统。builddir从 tarball 目录结构提取为hwloc-hwloc-2.14.0前缀hwloc- 版本号。4.3 环境检查1. OHOS_SDK✅ OHOS_SDK/home/ohpkg/linux2. LLVM 工具链✅ aarch64-linux-ohos-clang3. 构建工具✅ gcc ✅ g ✅ cmake ✅make✅ autoconf ✅ automake ❌ libtool ← 缺失关键点hwloc 需要libtool2.2.6 或更高版本来运行autogen.sh。如果在环境检查中发现了缺失的构建工具务必在构建前安装。这是一个 autoconf 类库特有的依赖CMake 类库不需要。五、核心问题发现从两个编译错误入手5.1 审查结果总览问题严重度影响libtool 未安装 阻塞autogen.sh无法运行config.sub不识别ohos 阻塞configure无法执行Cairo/PCI/GL 不可用 可选禁用无关组件即可5.2 问题一libtool 未安装现象第一次运行autogen.sh时autoreconf: running: aclocal --force -I ./config configure.ac:70: error: libtool version 2.2.6 or higher is required configure.ac:70: the top level autom4te: error: /usr/bin/m4 failed with exit status: 63 aclocal: error: /usr/bin/autom4te failed with exit status: 63 autoreconf: error: aclocal failed with exit status: 63排查hwloc 使用 libtool 管理共享库的编译和安装。autoreconfautogen.sh 内部调用的工具需要libtool.m4宏文件来生成configure脚本和ltmain.sh。根因定位系统未安装libtool包。修复方案安装 libtoolsudoapt-getinstalllibtool libtool-bin安装后验证$ libtool--versionlibtool(GNU libtool)2.4.75.3 问题二config.sub 不识别 OHOS 操作系统现象configure 失败checking host system type... Invalid configuration aarch64-unknown-linux-ohos: OS ohos not recognized configure: error: /bin/bash .././config/config.sub aarch64-unknown-linux-ohos failed排查configure脚本首先调用config.sub来规范化主机类型三元组host triple。三元组aarch64-unknown-linux-ohos包含 CPUaarch64、厂商unknown、内核linux和操作系统ohos。config.sub需要将ohos识别为合法的操作系统名。根因定位config.sub是 GNU autoconf/automake/libtool 工具链的一部分由autogen.sh从系统/usr/share/libtool/build-aux/config.sub复制到项目目录中。这个文件维护了一份已知操作系统的白名单——包括 Linux、Android、FreeBSD、Fuchsia 等——但ohosOpenHarmony不在其中。具体来说config.sub中有两个位置需要修改操作系统名列表case $os in此处列出所有可识别的操作系统名称内核-OS 组合验证case $kernel-$os in此处验证内核与 OS 的合法组合修复前在config.sub中的相关上下文# 位置1操作系统名列表约第1755行|fuchsia*|redox*|bme*\|midnightbsd*|...|fiwix*);;# ← ohos 不在列表中走到 *) 分支报错# 位置2内核-OS 组合验证约第1774行linux-gnu*|linux-dietlibc*|linux-android*|linux-newlib*\|linux-musl*|linux-relibc*|linux-uclibc*);;# ← linux-ohos 不在列表中走到 *) 分支报错修复方案在autogen.sh运行后、configure运行前用sed在两处添加ohos支持。# 位置1在操作系统名列表中添加 ohos*sed-is/| fiwix* )/| fiwix* | ohos* )/config/config.sub# 位置2在 kernel-OS 组合中添加 linux-ohos*# 注意用行首 anchor 避免误匹配 uclinux-uclibc 行sed-i/^[[:space:]]*linux-gnu*/s/linux-uclibc* )/linux-uclibc* | linux-ohos* )/config/config.sub验证修补效果$grepohosconfig/config.sub|fiwix*|ohos*)# 位置1操作系统已识别|linux-musl*|linux-relibc*|linux-uclibc*|linux-ohos*)# 位置2组合已验证5.4 可选组件禁用hwloc 支持多种后端。OpenHarmony 上没有以下组件需要在 configure 时显式禁用--disable-cairo# 无 GUI 依赖--disable-pci# 无 PCI 总线--disable-gl# 无 OpenGL--disable-libudev# 无 udevOHOS 使用 devfs--disable-libxml2# 仅影响 XML 语法检查高级功能这些禁用的后端不影响 hwloc 的核心拓扑检测能力。CPU 拓扑、NUMA 节点、缓存层级等信息仍然可以通过/sys/devices/system/cpu和/proc/cpuinfo等标准 Linux 接口获取。六、构建验证6.1 完整的构建日志 Step 1: autogen.sh autoreconf: Entering directory . autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I ./config autoreconf: running: libtoolize --install autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --force-missing autoreconf: Leaving directory . OK Step 2: patch config.sub | fiwix* | ohos* ) | linux-musl* | linux-relibc* | linux-uclibc* | linux-ohos* ) OK Step 3: configure checking build system type... x86_64-pc-linux-gnu checking host system type... aarch64-unknown-linux-ohos checking for aarch64-unknown-linux-ohos-gcc... /home/ohpkg/linux/native/llvm/bin/aarch64-linux-ohos-clang checking for C compiler default output file name... a.out checking whether the C compiler works... yes ... config.status: creating Makefile config.status: creating hwloc.pc --- Probe / display I/O devices: LinuxIO Graphical output: no XML input / output: basic Plugin support: no OK Step 4: make make[1]: Entering directory arm64-v8a-build CC topology.lo CC traversal.lo CC distances.lo ... CC topology-linux.lo CCLD libhwloc.la make[1]: Leaving directory arm64-v8a-build OK Step 5: install make[2]: Entering directory arm64-v8a-build /usr/bin/install -c .../libhwloc.a /lycium/usr/hwloc/arm64-v8a/lib/libhwloc.a OK6.2 产物验证# 静态库大小$ls-lhlycium/usr/hwloc/arm64-v8a/lib/libhwloc.a -rw-r--r--1root root1.9M libhwloc.a# 目标架构验证$filelycium/usr/hwloc/arm64-v8a/lib/libhwloc.a libhwloc.a: current ar archive# 头文件查看$lslycium/usr/hwloc/arm64-v8a/include/hwloc.h hwloc.h# 主头文件6.3 安装产物结构lycium/usr/hwloc/arm64-v8a/ ├── lib/ │ ├── libhwloc.a # 静态库 (1.9 MB) │ ├── libhwloc.la # libtool archive │ └── pkgconfig/hwloc.pc # pkg-config 配置 ├── include/ │ ├── hwloc.h # 主头文件 │ └── hwloc/ (31个子头文件) # 子模块bitmap, helper, linux 等 ├── bin/ # 命令行工具 (hwloc-info, lstopo 等) └── share/ # 文档和 man pages七、经验总结7.1 config.sub 的运作机制config.sub是 autoconf 工具链中最容易被忽视但最关键的文件之一。它的职责是将用户输入的主机类型字符串如aarch64-unknown-linux-ohos规范化并验证操作系统是否在已知列表中。输入aarch64-unknown-linux-ohos │ ├─ 第1步按 - 分割 │ cpuaarch64, vendorunknown, kernellinux, osohos │ ├─ 第2步验证 CPU 架构 → aarch64 ✅ ├─ 第3步验证 OS 名称 → ohos → 不在白名单 → ❌ │ └─ 修复后添加 ohos* → ohos ✅通过这个流程我们可以理解为什么在其他 Linux 发行版上顺利编译的库到了 OpenHarmony 就需要修补config.sub——因为ohos这个操作系统名实在太新了。7.2 同类库适配对比对比维度hwloc (当前)raylibSDL构建系统autoconfCMakeCMake核心问题config.sub 不识别 OHOSMemory 平台缺链接库无显示后端修复方式sed 修补 config.subcmake 补丁 (LIBS_PRIVATE)配置开关禁用组件5 个 (cairo/pci/gl/udev/xml2)—X11/Wayland构建步骤autogen.sh → configure → makecmake → makecmake → make静态库大小1.9 MB2.6 MB5.1 MB7.3 鸿蒙化适配最佳实践autoconf 类库的适配分三步autogen.sh→ 修补config.sub→configure --host*linux-ohos。第一步可能缺失 libtool第二步是新增操作系统名的必经之路第三步则要禁用 OHOS 上不可用的组件。config.sub 的修补优先于其他修改很多 autoconf 库在首次编译到新平台时第一关就是config.sub。通过sed在autogen.sh后修补是最小侵入方案——不需要维护一个随着 libtool 版本变化的 patch 文件。禁用组件要过度而非不足在 configure 时显式--disable-*所有可疑组件比等待编译失败再回溯更快。hwloc 的 5 个--disable-*选项中有些如 Cairo在config.summary中显示为 “no” 也没关系——核心拓扑检测功能不受影响。构建主机的工具链完整性与目标平台无关hwloc 需要 libtool 来生成 configure 脚本但 libtool 本身只在构建主机上运行其版本与目标平台上的运行时无关。7.4 总结适配 autoconf 类库到 OpenHarmony 的关键不在于修改多少行 C 代码而在于理解三层工具链的传递关系主机上的 autoconf 生成 configureconfigure 调用 config.sub 验证目标平台最后才是交叉编译器编译源码。config.sub不认识ohos不是 bug——是整个工具链生态还没跟上新平台的速度。而我们开发者要做的就是在这个链条的最早环节插一脚告诉它“这个操作系统我认识。”八、相关文件一览thirdparty/hwloc/ ├── HPKBUILD # 交叉编译构建脚本 ├── LICENSE # BSD-3-Clause 许可证 ├── OAT.xml # 许可证合规配置 ├── README.OpenSource # 开源元数据声明 ├── README_zh.md # 中文说明文档 └── SHA512SUM # 源码包完整性校验HPKBUILD 中的关键配置# prepare() 中的核心逻辑# 1. 运行 autogen.sh 生成 configure# 2. 用 sed 修补 config/config.sub 添加 ohos 支持# 3. 设置交叉编译器# build() 中的关键配置../configure\--hostaarch64-unknown-linux-ohos\--targetaarch64-unknown-linux-ohos\CC$ccCXX$cxx\--enable-static --disable-shared\--disable-cairo --disable-pci --disable-gl\--disable-libudev --disable-libxml2