你正在为 **OpenWrt** 构建 `python3-protobuf` 包（使用 `.whl` 预编译二进制），但遇到关键问题： > ❗ `python3-protobuf` 的 wheel 中包含 **C++ 扩展模块**（如 `_message.cpython-*.so`），它在运行时依赖 `libstdc++.so.6`，而 OpenWrt 默认 **不提供 `libstdc++` 运行时库**（仅提供 `libstdcpp6` 包，但该包可能未被正确链接或未安装到目标 rootfs）。 你已通过 `find` 确认：`libstdc++.so.6` **确实存在于构建系统中**（例如在 `staging_dir/toolchain-.../lib/` 和 `root-mediatek/usr/lib/` 下），但 `ldd` 检查 protobuf 的 `.so` 仍显示 `not found` —— 这说明： - ✅ 库文件存在； - ❌ 但未被 `ld.so` 在运行时发现（缺少 `RPATH` / `RUNPATH`，且 `LD_LIBRARY_PATH` 不生效，`/etc/ld.so.cache` 未包含该路径）。 --- ### ✅ 核心目标 > **让 `python3-protobuf` 安装的 `_message.so` 等 C++ 扩展，在 OpenWrt 目标设备上能自动找到并加载 `libstdc++.so.6`（来自 `staging_dir/toolchain-.../lib/` 或 `root-mediatek/usr/lib/`）** 由于你使用的是 **预编译 manylinux2014 wheel**（含 `aarch64` C extension），它**默认链接的是 x86_64 Linux 发行版的 `libstdc++.so.6`**，与 OpenWrt 的 `glibc-2.22 + toolchain-gcc-8.4.0` ABI **不兼容**，直接复制会失败。 ✅ 正确做法是：**在 OpenWrt 构建阶段，用 `patchelf` 重写 wheel 解压出的 `.so` 文件的 `RPATH`，指向 OpenWrt staging dir 中的 `libstdc++.so.6`**。 --- ## ✅ 修改方案（完整、可落地、适配 OpenWrt 构建系统） ### ✅ 步骤概览 | 阶段 | 操作 | |------|------| | **1. 确保 `libstdcpp6` 包已正确安装到 target rootfs** | ✅ 你已在 `DEPENDS` 中添加 `+libstdcpp6`，但需确认它实际安装了 `libstdc++.so.6` 到 `/usr/lib/` | | **2. 在 `Build/Install` 后、`Package/install` 前，用 `patchelf` 修复 `.so` 的 `RPATH`** | ✅ 关键！将 `_message.so` 的 `RPATH` 改为 `$ORIGIN/../../usr/lib`（即相对路径，适配 OpenWrt 标准布局） | | **3. 确保 `patchelf` 可用** | ✅ OpenWrt SDK 默认不含 `patchelf`，需显式添加依赖 | --- ### ✅ 修改后的完整 Makefile（重点修改部分已高亮） ```makefile include $(TOPDIR)/rules.mk PKG_NAME:=protobuf PKG_VERSION:=6.33.5 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-cp39-abi3-manylinux2014_aarch64.whl PKG_HASH:=skip # ✅ 新增：声明对 patchelf 的构建依赖（确保 build host 有 patchelf） BUILD_DEPENDS += patchelf/host include $(INCLUDE_DIR)/package.mk include ../python3-package.mk include ../python3-host.mk define Package/python3-protobuf SECTION:=lang CATEGORY:=Languages SUBMENU:=Python TITLE:=Python bindings for protobuf DEPENDS:= \ +python3-light \ +python3-setuptools \ +python3-six \ +python3-enum34 \ +python3-functools32 \ +libstdcpp6 # ✅ 确保目标设备安装 libstdc++.so.6 到 /usr/lib/ endef define Package/python3-protobuf/description Protocol Buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. This package provides the pure-Python runtime library for Python 3. endef define Build/Prepare mkdir -p $(PKG_BUILD_DIR) cp $(DL_DIR)/$(PKG_SOURCE) $(PKG_BUILD_DIR)/package.whl || true endef Build/Configure=$(Build/Default/Configure) Build/Compile=$(Build/Default/Compile) define Build/Compile $(call Build/Compile/PyMod,,true) endef # ✅ 新增：Build/Install 阶段解压 wheel 并 patch RPATH define Build/Install # 1. 创建临时解压目录 mkdir -p $(PKG_BUILD_DIR)/unpacked # 2. 解压 wheel（注意：wheel 是 zip 格式） unzip -q $(DL_DIR)/$(PKG_SOURCE) -d $(PKG_BUILD_DIR)/unpacked/ # 3. 查找所有 .so 文件（C++ 扩展） find $(PKG_BUILD_DIR)/unpacked -name "*.so" | while read so; do \ echo "Patching RPATH in $$so"; \ # ✅ 关键：设置 RPATH 为 $ORIGIN/../../usr/lib # 解释：假设 so 路径为 /usr/lib/python3.9/site-packages/google/protobuf/pyext/_message.so # $ORIGIN = /usr/lib/python3.9/site-packages/google/protobuf/pyext # $ORIGIN/../../usr/lib => /usr/lib → 正好是 libstdcpp6 安装位置 $(STAGING_DIR_HOST)/bin/patchelf \ --set-rpath '$$ORIGIN/../../usr/lib' \ "$$so" || { echo "ERROR: patchelf failed on $$so"; exit 1; }; \ done # 4. 重新打包为 wheel（可选，但推荐：避免 install 阶段重复解压） cd $(PKG_BUILD_DIR)/unpacked && zip -qr $(PKG_BUILD_DIR)/patched.whl . endef # ✅ 修改 install 阶段：使用已 patch 的 wheel define Package/python3-protobuf/install mkdir -p $(1)/usr/lib/python$(PYTHON3_VERSION)/site-packages # 解压已 patch 的 wheel unzip -q $(PKG_BUILD_DIR)/patched.whl -d $(1)/usr/lib/python$(PYTHON3_VERSION)/site-packages/ # 清理 dist-info 和 .data（保持干净） rm -rf $(1)/usr/lib/python$(PYTHON3_VERSION)/site-packages/{*.dist-info,.data} endef $(eval $(call BuildPackage,python3-protobuf)) ``` --- ### ✅ 关键说明 & 原理 | 项目 | 说明 | |------|------| | **`BUILD_DEPENDS += patchelf/host`** | 告诉 OpenWrt 构建系统：编译本包前，先构建 `patchelf` 工具（位于 `staging_dir/host/bin/patchelf`）。OpenWrt SDK 默认提供此包。 | | **`$(STAGING_DIR_HOST)/bin/patchelf`** | OpenWrt 构建时 `patchelf` 的标准路径（不是 `/usr/bin/patchelf`！） | | **`--set-rpath '$$ORIGIN/../../usr/lib'`** | 使用 `$$ORIGIN`（双 `$` 是 Makefile 转义）表示 `.so` 文件自身所在目录；`../../usr/lib` 向上两级再进 `/usr/lib`，最终解析为 `/usr/lib` —— 这正是 `libstdcpp6` 包安装 `libstdc++.so.6` 的位置（验证：`ls $(STAGING_DIR_TARGET)/usr/lib/libstdc++.so.6`）。✅ 完全符合 OpenWrt 标准文件系统布局。 | | **为什么不用绝对路径如 `/usr/lib`？** | 因为 `RPATH` 中写死 `/usr/lib` 在 OpenWrt 上虽可行，但 `$$ORIGIN` 更健壮（支持 relocatable install），且避免跨平台路径硬编码。 | | **`libstdcpp6` 是否真安装了 `libstdc++.so.6`？** | ✅ 是的。OpenWrt 的 `libstdcpp6` 包（`package/libs/libstdcpp6/Makefile`）会将 `staging_dir/toolchain-*/lib/libstdc++.so.6` 复制到 `$(STAGING_DIR_TARGET)/usr/lib/`，并在 `Package/libstdcpp6/install` 中写入 `$(1)/usr/lib/`。只要 `DEPENDS` 中有 `+libstdcpp6`，目标设备就会有该文件。 | --- ### ✅ 验证是否成功（构建后检查） 1. **在 SDK 中构建后，检查生成的 `.so`：** ```bash # 进入 SDK 目录 cd build_dir/target-aarch64_cortex-a53_glibc-2.22-fusion_pro_2.5g_un_v1/protobuf-6.33.5/ # 查看 patch 后的 so $(STAGING_DIR_HOST)/bin/patchelf --print-rpath \ unpacked/google/protobuf/pyext/_message.cpython-39-aarch64-linux-gnu.so # 应输出：$ORIGIN/../../usr/lib ``` 2. **在目标设备上运行：** ```bash # 登录 OpenWrt 设备 ldd /usr/lib/python3.9/site-packages/google/protobuf/pyext/_message.cpython-39-aarch64-linux-gnu.so | grep stdc++ # ✅ 应显示：libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x...) python3 -c "import google.protobuf; print('OK')" # ✅ 不再报错 "libstdc++.so.6: cannot open shared object file" ``` --- ### ⚠️ 注意事项（避坑指南） | 问题 | 解决方案 | |------|-----------| | **`patchelf` 报错 `cannot find section .dynamic`** | 说明该 `.so` 是纯 Python（无 C extension）或已 strip。用 `file xxx.so` 确认是否为 `ELF 64-bit LSB shared object`；若 `file` 显示 `data`，说明 wheel 是纯 Python 版（无需 patch）——但你的 `manylinux2014_aarch64.whl` 必含 C extension，应为 ELF。 | | **`_message.so` 名称因 Python 版本不同而异**（如 `cpython-310-aarch64-linux-gnu.so`） | `find ... -name "*.so"` 已覆盖所有变体，安全。 | | **OpenWrt target 使用 musl libc？** | ❌ 你用的是 `glibc-2.22`（见 `staging_dir/target-aarch64_cortex-a53_glibc-2.22-...`），所以 `libstdc++` 兼容。musl 用户需用 `libstdcpp-musl`，但你的环境是 glibc。 | | **`libstdc++.so.6` 版本太旧（GCC 8.4.0）导致符号缺失？** | `protobuf 6.33.5` 编译于 manylinux2014（GCC 4.8+），与 GCC 8.4.0 的 `libstdc++` ABI 兼容（向后兼容）。若仍报 `undefined symbol: _ZSt28__throw_bad_array_new_lengthv` 等，说明 wheel 编译用了更新的 GCC（如 11+），此时需换用 `--no-binary=protobuf` 源码编译。 | ---