bingo build编译超时退出

交流互助区
1

问题描述

添加component_drivers组件后由于触发该组件的源码编译，导致bingo build超时退出（在此之前该组件我已经单独使用bingo build构建出包）

环境信息

  • 操作系统：[Ubuntu 24.04]

  • 软件版本：[OpenUBMC2509]

重现步骤

期望结果

正常构建，和其它组件一样，显示早已安装

实际结果

该组件依旧会从源码进行编译，导致整个固件包构建超时

图片
图片1863×457 40.2 KB

2

答案内容由AI生成，仅供参考：

:pushpin: 结论

您遇到的 bingo build 编译超时问题，实质是 Conan 未能命中 component_drivers 的预构建二进制包，从而触发了耗时极长的源码重建流程。
根本原因极可能是 profile 配置差异、远程仓库未正确上传/访问 或 依赖版本漂移所致。

:white_check_mark: 解决方向：确保 component_drivers 在相同 profile 下构建并上传至远程仓库，并在完整构建时使用 lockfile 固化依赖，避免重建。

如果您可以提供 bingo build 所用的完整 profile 内容，可进一步比对差异点。

点击此处查看详细分析解答

关于 bingo build 编译 component_drivers 组件超时退出的问题分析

根据您提供的问题描述，bingo build 在集成 component_drivers 组件时未使用已构建的二进制包，而是选择从源码重新编译，最终导致构建过程超时退出。以下结合知识库内容为您系统性地分析该问题的原因、机制与潜在解决方案。

:magnifying_glass_tilted_left: 问题核心

即使 component_drivers 已成功构建并上传至远程仓库（您已独立出包），在执行 bingo build 构建完整固件时，Conan 仍判定该包“不可用”，触发从源码构建（Building from source），引发编译耗时过长乃至超时。

从您提供的日志片段可明确看到：

component_drivers/1.2.300@openumbc/stable: Building from source

表明 Conan 认为没有满足当前配置的预编译二进制包可用，必须重新构建。

:puzzle_piece: 根本原因分析（基于上下文推导）

:white_check_mark: 已知前提

  1. component_drivers 是一个复杂组件，包含多个底层驱动实现（如南向网卡驱动）。
  2. 它依赖众多其他组件（libmcpp, libsoc_adapter, lua jit, skynet 等）。
  3. bingo build 是基于 Conan 的构建系统，通过 conan lock create 生成依赖锁文件，决定是否使用本地/远程二进制包。

:cross_mark: 潜在导致“重新编译”的常见原因（匹配知识库 & 您的场景）

可能原因 对应证据或机制说明
1. Profile 配置不匹配 bingo build 使用的 profile（如 profile.luajit.ini, profile.dt.ini）中的配置（如 build_type=Debug, enable_luajit=True, board_name=openUBMC）与 component_drivers 原始构建时的配置存在差异，导致 Conan 认为现有二进制包不兼容。
2. Conan 远程仓库未正确设置或认证失败 若您使用的 Conan 仓库 URL、凭证错误，或网络问题导致无法拉取远程包，则 Conan 自动回退到源码构建。参考搜索结果中有“卡在conan认证失效”的问题。
3. 依赖版本锁定不一致（Lockfile 不匹配） 如果 manifest.yml 中对 component_drivers 或其子依赖（如 libmcpp/1.Y.Z）使用了模糊版本（Y.Z），可能导致解析出不同的依赖图，进而要求重新构建。
4. 包签名 / 加密配置差异（如 hpm_encrypt） 若目标构建启用了签名或加密（如 [hpm_encrypt] enable=true），而原始 component_drivers 包未包含相应支持，则 Conan 无法复用旧包。参考搜索结果 [4] 提到加密配置影响构建行为。
5. 编译环境变化（Docker 镜像、GCC 版本等） 日志中显示：compiler=gcc compiler.version=7.3。若原始包是在不同编译器版本（如 9.x）下构建的，Conan 会视为不兼容。
6. component_drivers 的 Conan 包未正确上传到远程 虽然本地 conan install 成功，但若未执行 conan upload 到 openubmc_dev 或其他共享仓库，他人或其他构建环境自然无法获取该二进制包。

:books: 支持证据（来自知识库）

  • Xiapengcheng 在构建 component_drivers 时也遇到类似路径错误和定制脚本失败问题，说明该组件构建过程较敏感且易受环境影响。
  • bingo build 依赖 Conan 的 lockfile 机制，命令如下：
    conan lock create . -pr=profile.luajit.ini -pr:b profile.dt.ini -s:a build_type=Debug ...
    若 profile 配置与原始构建不同，则 lockfile 不会命中已构建的二进制包。
  • 搜索结果中多次提到：
    • “卡在conan认证失效” → 表明远程访问失败可能导致行为异常。
    • “白牌包只能用 bmcgo 构建，bingo 不支持” → 不同构建工具/流程可能生成不同 signature 的包，需注意兼容性。
  • component_drivers 的目录结构复杂（drivers/, libraries/, gen/），代码生成和构建过程耗时更长，一旦触发源码编译极易超时。

:white_check_mark: 推荐解决方案与排查步骤

:white_check_mark: 1. 确认远程仓库配置与认证

conan remote list
# 应包含 openubmc_dev 或对应远程地址，且 enabled: True
conan user -r openubmc_dev
# 确保已登录认证

:white_check_mark: 2. 检查 profile 配置一致性

比对当前 bingo build 使用的 profile.luajit.ini 和 profile.dt.ini 与当初构建 component_drivers 时是否完全一致，特别是：

  • build_type（Debug/Release）
  • board_name
  • enable_luajit
  • module_symvers
  • 编译器版本要求

推荐：为 component_drivers 单独执行一次 bingo build -pr=xxx 使用相同 profile 构建并上传，确保二进制包存在于远程。

:white_check_mark: 3. 强制使用远程二进制包（禁止源码构建）

可在构建命令中添加 Conan 参数：

bingo build -- -o component_drivers/*:allow_source_rebuilding=False

或检查是否可通过环境变量禁止 fallback：

CONAN_ALLOW_SOURCE_FORKS=0 bingo build ...

:white_check_mark: 4. 检查并上传 component_drivers 包到远程

确保执行过：

conan upload "component_drivers*" --all -r openubmc_dev

否则仅本地缓存存在，无法被 CI/其他构建复用。

:white_check_mark: 5. 使用锁文件机制固定依赖

# 第一次构建生成 lockfile
bingo build --build=missing --lockfile-out=openubmc.lock

# 后续构建使用锁定依赖
bingo build --lockfile=openubmc.lock

这能确保每次都使用相同的二进制依赖，避免重新解析导致重编译。

:white_check_mark: 6. 检查 manifest.yml 中的版本定义

确保 component_drivers 的版本为精确版本而非通配符：

- conan: component_drivers
  version: 1.2.300@openumbc/stable

避免因版本漂移导致重新构建。

:white_check_mark: 建议实践总结

最佳实践 说明
:white_check_mark: 统一构建 profile 所有组件使用相同 profile 构建，提高二进制兼容性
:white_check_mark: 构建后立即上传 确保预构建包可在团队内共享
:white_check_mark: 使用 lockfile 管理依赖 保证构建可重复性和稳定性
:white_check_mark: 避免频繁修改 component_drivers 源码 该组件构建开销大，建议通过接口隔离频繁变更部分
:white_check_mark: 超时阈值可调（如有权限） 对于允许长时间构建的 CI 环境，适当延长超时时间以通过首次构建

:pushpin: 结论

您遇到的 bingo build 编译超时问题，实质是 Conan 未能命中 component_drivers 的预构建二进制包，从而触发了耗时极长的源码重建流程。
根本原因极可能是 profile 配置差异、远程仓库未正确上传/访问 或 依赖版本漂移所致。

:white_check_mark: 解决方向：确保 component_drivers 在相同 profile 下构建并上传至远程仓库，并在完整构建时使用 lockfile 固化依赖，避免重建。

如果您可以提供 bingo build 所用的完整 profile 内容，可进一步比对差异点。

相关链接：

  1. 再添加了组件后，执行bingo build报错
  2. bingo build报错，任务 work.build.conan 执行失败
  3. 无签名UBMC上无法继续更新BMC固件
  4. 25.06版本storage组件编译问题
  5. openUBMC
1 个赞
3

缺少二进制就会从源码构建，你可以将二进制上传到conan仓中，但考虑到构建参数变更、工具链变更、组件option变更等各种因素，缺少二进制几乎是必然的现象，如果缺少，从源码构建即可。

可参考conan的官方文档了解conan如何判断缓存的命中逻辑。

4

好的，感谢，我看看分享的文档

5

如有疑问，可单独再开帖子，此帖关闭。