关于在1230基线中编译Storage组件自带SML库的分析与解决方案

根据您提供的问题描述和系统环境信息，以下是对1230基线环境下如何激活并正确编译Storage组件内置SML库的详细分析与解决方案。

问题分析

1. 当前现状

• Storage仓已包含SML源码：路径为 storage/src/lualib-src/sml，内含多个子模块（如 sml_lsi, sml_pmc, sml_base 等）。
• 现有构建方式依赖预编译库：
  • libsml_lsi.so 和其他相关库目前通过高可用组件或闭源依赖引入，为二进制形式（.so 文件）。
  • Storage组件本身并未强制开启从源码构建SML的功能。
• 检测到编译开关存在：
  • 在 service.json 中定义了两个关键选项：

    "sml_open": {
      "description": "使能storage仓sml目录",
      "option": [true, false],
      "default": false
    },
    "storelib_enable": {
      "description": "使能其他厂商存储管理库",
      "option": [true, false],
      "default": false
    }
    

  • 其中 sml_open = true 是启用内部SML源码构建的关键配置。

2. 错误原因分析

当您尝试开启 sml_open=true 构建时出现如下编译失败：

fatal error: lsi/storelib.h: No such file or directory
#include "lsi/storelib.h"

fatal error: pmc/pstore.h: No such file or directory
#include "pmc/pstore.h"

根本原因：

SML库依赖的底层厂商SDK头文件（如Broadcom/LSI、PMC）未在构建环境中提供。

尽管Storage组件中包含了SML的适配层源代码，但这些源码本身依赖于外部的闭源RAID卡厂商SDK头文件（例如 storelib.h, pstore.h），而这些头文件：

• 不是开源组件的一部分
• 未包含在当前Conan包或源码树中
• 需要由平台方或厂商单独提供（通常以专用Conan包或私有仓库形式）

因此，即使启用了 sml_open 开关，由于缺少必要的头文件依赖，构建过程无法继续。

解决方案：如何正确启用并构建SML库

要实现在1230基线下从源码成功构建SML库，需满足以下条件：

步骤一：确认并引入必要的厂商SDK依赖

必须确保以下组件可通过 Conan 或其他方式正确解析并提供头文件路径：

操作建议：

修改 conanfile.py 或 manifest.yaml，显式声明对这些SDK开发包的依赖：

# manifest.yaml
requires:
  - conan: broadcom-sdk/1.0.0@openubmc/internal
  - conan: pmc-sdk/1.2.0@openubmc/internal
  - conan: huawei-sml-sdk/latest@openubmc/internal

注意：这些包需提前上传至企业内网 Conan 私服，并确保构建机器可访问。

步骤二：正确启用 sml_open 编译选项

在构建命令或配置中明确设置：

bmcgo build --option sml_open=True --option storelib_enable=True

或在构建配置文件（如 vars.json）中设定：

{
  "sml_open": true,
  "storelib_enable": true
}

storelib_enable=True 通常用于激活对非华为RAID卡的支持，与 sml_open 配套使用更佳。

步骤三：验证编译系统路径包含机制

确保 CMakeLists.txt 中对头文件包含路径的处理是动态且可扩展的。

例如，在 storage/src/lualib-src/sml/sml_lsi/CMakeLists.txt 中应有类似：

include_directories(
    ${CMAKE_CURRENT_SOURCE_DIR}/inc
    ${BROADCOM_SDK_INCLUDE_DIR}  # 通过Conan注入
)

可通过 Conan 的 cpp_info.includedirs 自动导出头文件路径，并在 CMake 中引用。

步骤四：使用 bmcgo 管理构建流程

由于 bmcgo 是 openUBMC 的核心构建工具（如知识库所示，其版本影响构建行为），请确保：

• 使用兼容的 bmcgo 版本（推荐 ≥0.5.370）
• 构建前清除旧缓存（避免使用过期组件）：

bmcgo clean --all
bmcgo build --force --option sml_open=true

提示：可配合 --dry-run 查看依赖解析是否正确加载了SDK包。

替代方案（临时验证用）

若短期内无法获取闭源SDK头文件，但仍需验证SML构建流程，可采用以下方式：

方案A：预置空头文件（仅用于PoC）

创建模拟头文件，供编译通过（适用于调试构建逻辑，不能用于生产）：

// mock/lsi/storelib.h
#ifndef _LSI_STORELIB_H_
#define _LSI_STORELIB_H_

typedef struct { int dummy; } STOR_LIB_INFO;

#endif

然后将 mock/ 添加进 include path。

方案B：切换为 stub 模式构建

在 CMakeLists.txt 中添加判断：

if(NOT DEFINED BROADCOM_SDK_AVAILABLE)
    add_definitions(-DUSE_STUB_SML)
endif()

并在代码中用 #ifdef USE_STUB_SML 包裹依赖厂商头的部分。

总结：实现从源码构建SML库的关键条件

条件	是否满足	说明
开启 sml_open 编译选项	可配置	在 service.json 中启用
提供厂商SDK头文件	通常缺失	需引入 Broadcom/PMC/Huawei SDK Conan包
构建系统支持自动包含路径	Conan+CMake支持	依赖配置正确
使用正确版本 bmcgo	推荐 0.5.370+	避免僵尸进程等问题

参考资料（来自知识库）

• 神码_刘杰 曾成功解决类似编译问题（见文档chunk #1），方法为：移除冲突库并清理依赖缓存
• libsml_lsi.so 被证实需通过 storelib_enable=true 打包进固件（见 chunk #2）
• SML Library 本质是封装厂商SDK的抽象层，依赖底层 .so 和头文件（见 KG 实体描述）

最终建议

要实现 storage 组件内建 SML 库的源码构建，必须：

1. 打通闭源SDK依赖链：将 lsi/storelib.h、pmc/pstore.h 等头文件以 Conan 包形式纳入依赖管理；
2. 启用 sml_open=true 构建选项；
3. 确保 manifest.yaml 正确声明SDK依赖并配置包含路径；
4. 使用高版本 bmcgo 构建并清理缓存。

如果您所在组织尚无权限获取上述SDK头文件，请联系平台提供方或华为技术支持，申请相应的开发套件（SDK Dev Kit）以支持自主构建。

如您能提供更多关于所用RAID卡型号（如9560-8i）及具体SDK来源的信息，可进一步细化解决方案。

相关链接：

1. storage组件编译问题
2. storage组件的Lua、C++、C日志怎么聚合到同一个文件
3. raid卡libsml_lsi.so动态库缺失
4. 9500-8i下硬盘信息温度获取为0xff
5. storage | 文档中心 | openUBMC