尧图网站建设 
存储分布式文件系统对象存储云原生【免费下载链接】cubefscloud-native distributed storage项目地址https://gitcode.com/gh_mirrors/cu/cubefs点击查看免费下载CubeFS 作为云原生分布式存储系统其主仓库cubefs与 blobstore 纠删码子系统都重度依赖 rocksdb、zstd、lz4、bzip2、zlib、snappy 等 C/C 第三方库构建链路复杂。本篇指南以官方 FAQ 中「编译问题」章节为骨架结合仓库内 Makefile、build/build.sh、build.sh、build/cgo_env.sh 等真实构建脚本系统梳理从「本机编译通过但部署机器无法启动」到「ZSTD 符号缺失」「rocksdb 头文件缺失」「bz2/z 链接失败」「警告即错误」「ARM 平台交叉编译」等高频编译故障的成因与修复手段。读完本文你将能独立定位并解决 CubeFS 编译链路上绝大多数环境类报错并掌握 ARM64 版本从环境变量设置到 Java SDK 打包的完整流程。一、编译体系概览先看懂 CubeFS 的构建链路在逐个排错之前先明确 CubeFS 的构建入口与依赖管理方式这对理解报错来源至关重要。根目录 Makefile 是总入口make all会依次构建server、client、cli、libsdk、fsck、fdstore、bcache、blobstore、deploy等目标其中make libsdk会先产出libcfs.so再调用mvn clean package打包 Java SDK见 build/build.sh 中build_libsdk函数。build/build.sh 中的pre_build函数负责按顺序编译 zlib1.2.13、bzip21.0.6、lz41.8.3、zstd1.4.0、snappy1.1.7、tcmallocgperftools 2.9.1与 rocksdb6.3.6对应源码压缩包位于 depends 目录编译产物静态库与头文件输出到build/lib与build/include。编译时通过CGO_CFLAGS、CGO_LDFLAGS等环境变量把 C 依赖注入 Go 的 cgo 构建流程具体参数可参考 build/cgo_env.sh-L${BuildPath}/lib -lrocksdb -lz -lbz2 -lsnappy -llz4 -lzstd -lstdc。这也是后续所有「找不到库 / 符号」类报错的根源所在。二、本机编译成功但其他机器无法启动现象在开发机上make编译一切正常二进制拷到其他机器后启动即报「找不到共享库」或直接无法运行。原因CubeFS 部分模块如cfs-server、cfs-cli、blobstore 的clustermgr、blobnode、shardnode等以CGO_ENABLED1方式链接了 rocksdb 及其压缩依赖库产物对目标机器的动态库环境有硬性要求。排查与解决步骤确认 rocksdb 是以可移植静态库方式编译的。必须使用PORTABLE1 make static_lib命令编译 rocksdb。这与仓库构建脚本一致——build/build.sh 的build_rocksdb函数正是以PORTABLE1 make -j$1 ... static_lib编译并make install-static安装到build/lib。PORTABLE模式生成的库不针对本机 CPU 指令集做特定优化从而保证二进制在异构机器上可迁移。使用ldd检查依赖对编译出的可执行文件执行ldd binary查看输出中标记为not found的库常见如librocksdb.so、libz.so、libbz2.so、libzstd.so、liblz4.so、libsnappy.so、libstdc.so.6等。在目标机器上安装缺失的库例如yum install zlib-devel bzip2-devel zstd-devel lz4-devel snappy-develCentOS/RHEL 系或apt-get install zlib1g-dev libbz2-dev libzstd-dev liblz4-dev libsnappy-devDebian/Ubuntu 系。安装完成后执行ldconfig刷新动态链接器缓存再次ldd确认所有依赖均已解析。三、ZSTD_versionNumber未定义现象编译 rocksdb 或链接阶段报ZSTD_versionNumber未定义undefined reference之类的错误。成因rocksdb 构建过程通过build_tools/build_detect_platform脚本自动探测系统中是否安装了 zstd探测成功才会在编译宏中加入-DZSTD并在链接参数中加入-lzstd。当探测脚本判定失败、而代码路径仍引用 zstd 符号时就会产生该报错。官方文档给出两种解法方式一通过CGO_LDFLAGS显式指定库路径推荐用于多机器部署export CGO_LDFLAGS-L/usr/local/lib -lrocksdb -lzstd注意这种方式要求其他部署机器上同样安装 zstd 库否则二进制运行时仍会缺库可结合第二节的ldd/ldconfig流程处理。CubeFS 自身的 build/cgo_env.sh 也是同类思路——把-lrocksdb -lz -lbz2 -lsnappy -llz4 -lzstd -lstdc全部注入CGO_LDFLAGS。方式二删除自动探测 zstd 的脚本片段定位 rocksdb 源码树下的探测脚本文档示例路径为rocksdb-5.9.2/build_tools/build_detect_platform注意版本号随所用 rocksdb 版本不同而不同删除以下自动探测内容改为在EXTRA_CXXFLAGS等参数中手工指定-DZSTD与-lzstd# Test whether zstd library is installed $CXX $CFLAGS $COMMON_FLAGS -x c - -o /dev/null 2/dev/null EOF #include zstd.h int main() {} EOF if [ $? 0 ]; then COMMON_FLAGS$COMMON_FLAGS -DZSTD PLATFORM_LDFLAGS$PLATFORM_LDFLAGS -lzstd JAVA_LDFLAGS$JAVA_LDFLAGS -lzstd fi仓库侧的参考实现可见 build/build.sh 的build_rocksdb它在PORTABLE1 make时显式传入EXTRA_CXXFLAGS-fPIC ... -DZLIB -DBZIP2 -DSNAPPY -DLZ4 -DZSTD ...即不依赖探测脚本而是把全部压缩库宏一次性编译进 rocksdb这可以作为「确定性构建」的样板。四、fatal error: rocksdb/c.h: no such file or directory现象编译纠删码blobstore子系统时cgo 预处理阶段报rocksdb/c.h头文件找不到。排查顺序确认头文件是否真的存在。先检查.deps/include/rocksdb目录下是否有报错所指的c.h文件。注意在当前仓库的构建脚本 build/build.sh 中依赖头文件的安装路径为build/includerocksdb 安装时通过INSTALL_PATH${BuildPath}写入build/include/rocksdb如果仓库版本较新应优先检查build/include/rocksdb/c.h。如果文件存在执行source env.sh指项目约定的环境准备脚本用于导入CGO_CFLAGS/CGO_LDFLAGS等变量其实际内容可参照 build/cgo_env.sh后重新编译。如果文件不存在或仍报错将.deps或build/out、build/lib、build/include目录下 rocksdb 相关的文件全部清理重新执行构建。仓库中对应的清理入口是make dist-clean它会删除build/bin、build/out、build/lib、build/include全部构建产物见 Makefile 与 build/build.sh 的dist_clean函数随后重新make即可触发 rocksdb 从头编译。五、cannot find -lbz2与cannot find -lz现象链接阶段报/usr/bin/ld: cannot find -lbz2或/usr/bin/ld: cannot find -lz。原因系统缺少 bzip2 / zlib 的开发包devel 包导致链接器找不到libbz2.so/libz.a/libz.so。解决cannot find -lbz2确认安装bzip2-devel版本 1.0.6 及以上。仓库侧 bzip2 依赖版本即为 1.0.6见 build/build.sh 的BZIP2_VER1.0.6。cannot find -lz确认安装zlib-devel版本 1.2.7 及以上。仓库侧 zlib 依赖版本为 1.2.13见 build/build.sh 的ZLIB_VER1.2.13。安装后同样建议执行ldconfig刷新链接器缓存再重新编译。若本机缺包、又不想逐个安装系统包也可以让构建脚本走自带依赖CubeFS 的 build/build.sh 会从 depends 目录解压并静态编译这些压缩库到build/lib这正是官方推荐的自包含构建路径。六、cc1plus: all warnings being treated as errors构建 rocksdb 报错现象使用较新版本 gcc如 Ubuntu 22.04 的 gcc 11.3.0编译 rocksdb 时g 把所有 warning 按 error 处理导致编译中断。解决通过环境变量关闭「warning 即 error」行为分模块处理针对 blobstore 模块进入blobstore目录在其env.sh文件中添加以下环境变量然后执行source env.sh后继续编译export DISABLE_WARNING_AS_ERRORtrue针对 cubefs 根目录在根目录的env.sh中添加导出环境变量export CXXFLAGS-Wno-errorxxx # 此选项可选开发者可根据实际情况调整选项值或者干脆注释掉或删除此行注意编译选项开关可能因 gcc 版本不同存在差异。官方文档注明以下选项在gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0版本上测试通过不同发行版 / 工具链版本需要按实际报错调整。仓库侧的对应实现也可以佐证该问题的普遍性在 build/build.sh 的build_rocksdb中会根据 gcc 版本自动追加-Wno-errordeprecated-copy -Wno-errorpessimizing-movegcc 9 及以上使用 clang 时还会追加-Wno-errorshadow -Wno-errorunused-but-set-variable随后统一再补-Wno-unused-variable -Wno-unused-function——这正是为了压制新版编译器在 rocksdb 6.3.6 源码上产生的历史性警告。若使用仓库默认构建脚本上述参数已内置若手动编译 rocksdb 遇到同类报错可参照该函数自行追加-Wno-error...。七、ARM 版本编译arm64CubeFS 支持在 x86 开发机上交叉编译 ARM 版本。根目录 build.sh 提供了三种模式arm64_gcc9配合 Ubuntu focal 的 gcc-9-aarch64 交叉工具链、arm64_gcc4配合 gcc-4.9-aarch64 工具链支持 CentOS 7、arm64等价于arm64_gcc4并会在编译前通过get_rocksdb_compress_dep拉取 zlib、bzip2、zstd、lz4 的压缩依赖。7.1 设置环境变量并编译编译 ARM 版本前首先修改环境变量export CPUTYPEarm64_gcc4确认环境变量正确后编译对应模块或全量编译。以编译 libsdk 为例在 cubefs 目录下执行make libsdk该命令会先后触发build_libsdkpre产出libcfs.so对应 build/build.sh 中CGO_ENABLED1 go build -buildmode c-shared与build_libsdk将libcfs.so复制进java/src/main/resources/后执行mvn clean package打包 jar见 build/build.sh。执行过程中若报缺少某个库按需安装即可常见的有yum install cmake yum install g yum install go yum install maven根据编译环境的实际情况将缺失依赖补齐后再次编译一般即可成功。7.2 可能遇到的错误Java 找不到类定义如果遇到 Java 报「找不到类定义」之类的错误例如下图所示根因Maven 安装目录下lib子目录如/usr/share/maven/lib/缺少对应的 jar 包。通常该目录下的大部分 jar 包是 Java 安装目录下 jar 包的软连接当 Java 版本与 Maven 自带的 jar 集合不匹配时就会缺类。此时有两种解决办法。方法一软连接 Java 目录中的同类 jar到 Java 安装目录下根据报错中缺失的类名找到相似的 jar 包然后软连接到 Maven 的lib目录下。例如报错涉及FailureAccess类时在/usr/share/java/guava/目录下可以找到failureaccess.jar将其软连接到/usr/share/maven/lib/下即可ln -s /usr/share/java/guava/failureaccess.jar /usr/share/maven/lib/failureaccess.jar方法二从 Maven 中央仓库下载缺失 jar在 Maven 中央仓库mvnrepository.com中搜索报错中的关键类名找到包含该报错类的 jar 包后下载将其放入 Maven 库目录/usr/share/maven/lib/下即可cp 下载的jar包 /usr/share/maven/lib/完成后再执行make libsdkJava SDK 打包环节即可通过。八、总结与排错速查CubeFS 的编译故障绝大多数集中在C 依赖rocksdb 及其压缩库的探测、编译与链接三个环节本文涉及的排错可以归纳为一张速查表报错特征根因首选处理本机编译通过、其他机器无法启动动态库依赖缺失 / 非可移植编译PORTABLE1 make static_lib重编 rocksdbldd查缺并安装ldconfig刷新ZSTD_versionNumber未定义zstd 探测失败或未显式指定CGO_LDFLAGS指定-lzstd或删除探测脚本片段改为手工-DZSTDrocksdb/c.h: no such file or directory头文件缺失或环境变量未导入确认build/include/rocksdb/c.h存在后source env.sh否则make dist-clean重编cannot find -lbz2/cannot find -lz缺系统开发包安装bzip2-devel(≥1.0.6) /zlib-devel(≥1.2.7) 并ldconfigcc1plus: all warnings being treated as errors新 gcc 将警告视为错误blobstore 设DISABLE_WARNING_AS_ERRORtrue根目录设CXXFLAGS-Wno-errorxxxARM 编译缺 Java 类Maven lib 目录缺 jar软连接 Java 目录 jar或从 Maven 仓库下载放入/usr/share/maven/lib/编译链路涉及的具体构建参数、依赖版本与函数实现均可在 build/build.sh、build.sh、build/cgo_env.sh 及 Makefile 中找到对应代码佐证按上述步骤逐项排查即可让 CubeFS 在 x86 与 ARM 平台上稳定产出可部署的二进制。赞分享存储分布式文件系统对象存储云原生【免费下载链接】cubefscloud-native distributed storage项目地址https://gitcode.com/gh_mirrors/cu/cubefs点击查看免费下载相关推荐KOReader编译错误排查终极指南10个常见交叉编译问题解决方案KOReader编译错误排查终极指南10个常见交叉编译问题解决方案 KOReader是一款功能强大的电子书阅读器应用支持PDF、DjVu、EPUB、FB2等桌面应用跨平台嵌入式lz4/lz4交叉编译工具链从x86到ARM的完整指南lz4/lz4交叉编译工具链从x86到ARM的完整指南 LZ4是一款极速的无损压缩算法提供超过500MB/s每核心的压缩速度解压速度可达数GB/s。在嵌入存储系统编程radare2 Windows 原生构建指南从 Meson/Ninja 编译到静态 Blob 与交叉编译radare2 Windows 原生构建指南从 Meson/Ninja 编译到静态 Blob 与交叉编译 导读 本文以 doc/windows.md http逆向工程网络安全上一篇radix-vueReka UISwitch 组件完全指南SwitchRoot 属性、事件与插槽详解下一篇revm-ee-tests 集成测试指南基于快照机制验证 revm 与 op-revm 的 OP Stack 执行语义创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CubeFS 编译问题排查实战指南：从 rocksdb 静态库到 ARM 交叉编译的完整解决方案
存储分布式文件系统对象存储云原生【免费下载链接】cubefscloud-native distributed storage项目地址https://gitcode.com/gh_mirrors/cu/cubefs点击查看免费下载CubeFS 作为云原生分布式存储系统其主仓库cubefs与 blobstore 纠删码子系统都重度依赖 rocksdb、zstd、lz4、bzip2、zlib、snappy 等 C/C 第三方库构建链路复杂。本篇指南以官方 FAQ 中「编译问题」章节为骨架结合仓库内 Makefile、build/build.sh、build.sh、build/cgo_env.sh 等真实构建脚本系统梳理从「本机编译通过但部署机器无法启动」到「ZSTD 符号缺失」「rocksdb 头文件缺失」「bz2/z 链接失败」「警告即错误」「ARM 平台交叉编译」等高频编译故障的成因与修复手段。读完本文你将能独立定位并解决 CubeFS 编译链路上绝大多数环境类报错并掌握 ARM64 版本从环境变量设置到 Java SDK 打包的完整流程。一、编译体系概览先看懂 CubeFS 的构建链路在逐个排错之前先明确 CubeFS 的构建入口与依赖管理方式这对理解报错来源至关重要。根目录 Makefile 是总入口make all会依次构建server、client、cli、libsdk、fsck、fdstore、bcache、blobstore、deploy等目标其中make libsdk会先产出libcfs.so再调用mvn clean package打包 Java SDK见 build/build.sh 中build_libsdk函数。build/build.sh 中的pre_build函数负责按顺序编译 zlib1.2.13、bzip21.0.6、lz41.8.3、zstd1.4.0、snappy1.1.7、tcmallocgperftools 2.9.1与 rocksdb6.3.6对应源码压缩包位于 depends 目录编译产物静态库与头文件输出到build/lib与build/include。编译时通过CGO_CFLAGS、CGO_LDFLAGS等环境变量把 C 依赖注入 Go 的 cgo 构建流程具体参数可参考 build/cgo_env.sh-L${BuildPath}/lib -lrocksdb -lz -lbz2 -lsnappy -llz4 -lzstd -lstdc。这也是后续所有「找不到库 / 符号」类报错的根源所在。二、本机编译成功但其他机器无法启动现象在开发机上make编译一切正常二进制拷到其他机器后启动即报「找不到共享库」或直接无法运行。原因CubeFS 部分模块如cfs-server、cfs-cli、blobstore 的clustermgr、blobnode、shardnode等以CGO_ENABLED1方式链接了 rocksdb 及其压缩依赖库产物对目标机器的动态库环境有硬性要求。排查与解决步骤确认 rocksdb 是以可移植静态库方式编译的。必须使用PORTABLE1 make static_lib命令编译 rocksdb。这与仓库构建脚本一致——build/build.sh 的build_rocksdb函数正是以PORTABLE1 make -j$1 ... static_lib编译并make install-static安装到build/lib。PORTABLE模式生成的库不针对本机 CPU 指令集做特定优化从而保证二进制在异构机器上可迁移。使用ldd检查依赖对编译出的可执行文件执行ldd binary查看输出中标记为not found的库常见如librocksdb.so、libz.so、libbz2.so、libzstd.so、liblz4.so、libsnappy.so、libstdc.so.6等。在目标机器上安装缺失的库例如yum install zlib-devel bzip2-devel zstd-devel lz4-devel snappy-develCentOS/RHEL 系或apt-get install zlib1g-dev libbz2-dev libzstd-dev liblz4-dev libsnappy-devDebian/Ubuntu 系。安装完成后执行ldconfig刷新动态链接器缓存再次ldd确认所有依赖均已解析。三、ZSTD_versionNumber未定义现象编译 rocksdb 或链接阶段报ZSTD_versionNumber未定义undefined reference之类的错误。成因rocksdb 构建过程通过build_tools/build_detect_platform脚本自动探测系统中是否安装了 zstd探测成功才会在编译宏中加入-DZSTD并在链接参数中加入-lzstd。当探测脚本判定失败、而代码路径仍引用 zstd 符号时就会产生该报错。官方文档给出两种解法方式一通过CGO_LDFLAGS显式指定库路径推荐用于多机器部署export CGO_LDFLAGS-L/usr/local/lib -lrocksdb -lzstd注意这种方式要求其他部署机器上同样安装 zstd 库否则二进制运行时仍会缺库可结合第二节的ldd/ldconfig流程处理。CubeFS 自身的 build/cgo_env.sh 也是同类思路——把-lrocksdb -lz -lbz2 -lsnappy -llz4 -lzstd -lstdc全部注入CGO_LDFLAGS。方式二删除自动探测 zstd 的脚本片段定位 rocksdb 源码树下的探测脚本文档示例路径为rocksdb-5.9.2/build_tools/build_detect_platform注意版本号随所用 rocksdb 版本不同而不同删除以下自动探测内容改为在EXTRA_CXXFLAGS等参数中手工指定-DZSTD与-lzstd# Test whether zstd library is installed $CXX $CFLAGS $COMMON_FLAGS -x c - -o /dev/null 2/dev/null EOF #include zstd.h int main() {} EOF if [ $? 0 ]; then COMMON_FLAGS$COMMON_FLAGS -DZSTD PLATFORM_LDFLAGS$PLATFORM_LDFLAGS -lzstd JAVA_LDFLAGS$JAVA_LDFLAGS -lzstd fi仓库侧的参考实现可见 build/build.sh 的build_rocksdb它在PORTABLE1 make时显式传入EXTRA_CXXFLAGS-fPIC ... -DZLIB -DBZIP2 -DSNAPPY -DLZ4 -DZSTD ...即不依赖探测脚本而是把全部压缩库宏一次性编译进 rocksdb这可以作为「确定性构建」的样板。四、fatal error: rocksdb/c.h: no such file or directory现象编译纠删码blobstore子系统时cgo 预处理阶段报rocksdb/c.h头文件找不到。排查顺序确认头文件是否真的存在。先检查.deps/include/rocksdb目录下是否有报错所指的c.h文件。注意在当前仓库的构建脚本 build/build.sh 中依赖头文件的安装路径为build/includerocksdb 安装时通过INSTALL_PATH${BuildPath}写入build/include/rocksdb如果仓库版本较新应优先检查build/include/rocksdb/c.h。如果文件存在执行source env.sh指项目约定的环境准备脚本用于导入CGO_CFLAGS/CGO_LDFLAGS等变量其实际内容可参照 build/cgo_env.sh后重新编译。如果文件不存在或仍报错将.deps或build/out、build/lib、build/include目录下 rocksdb 相关的文件全部清理重新执行构建。仓库中对应的清理入口是make dist-clean它会删除build/bin、build/out、build/lib、build/include全部构建产物见 Makefile 与 build/build.sh 的dist_clean函数随后重新make即可触发 rocksdb 从头编译。五、cannot find -lbz2与cannot find -lz现象链接阶段报/usr/bin/ld: cannot find -lbz2或/usr/bin/ld: cannot find -lz。原因系统缺少 bzip2 / zlib 的开发包devel 包导致链接器找不到libbz2.so/libz.a/libz.so。解决cannot find -lbz2确认安装bzip2-devel版本 1.0.6 及以上。仓库侧 bzip2 依赖版本即为 1.0.6见 build/build.sh 的BZIP2_VER1.0.6。cannot find -lz确认安装zlib-devel版本 1.2.7 及以上。仓库侧 zlib 依赖版本为 1.2.13见 build/build.sh 的ZLIB_VER1.2.13。安装后同样建议执行ldconfig刷新链接器缓存再重新编译。若本机缺包、又不想逐个安装系统包也可以让构建脚本走自带依赖CubeFS 的 build/build.sh 会从 depends 目录解压并静态编译这些压缩库到build/lib这正是官方推荐的自包含构建路径。六、cc1plus: all warnings being treated as errors构建 rocksdb 报错现象使用较新版本 gcc如 Ubuntu 22.04 的 gcc 11.3.0编译 rocksdb 时g 把所有 warning 按 error 处理导致编译中断。解决通过环境变量关闭「warning 即 error」行为分模块处理针对 blobstore 模块进入blobstore目录在其env.sh文件中添加以下环境变量然后执行source env.sh后继续编译export DISABLE_WARNING_AS_ERRORtrue针对 cubefs 根目录在根目录的env.sh中添加导出环境变量export CXXFLAGS-Wno-errorxxx # 此选项可选开发者可根据实际情况调整选项值或者干脆注释掉或删除此行注意编译选项开关可能因 gcc 版本不同存在差异。官方文档注明以下选项在gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0版本上测试通过不同发行版 / 工具链版本需要按实际报错调整。仓库侧的对应实现也可以佐证该问题的普遍性在 build/build.sh 的build_rocksdb中会根据 gcc 版本自动追加-Wno-errordeprecated-copy -Wno-errorpessimizing-movegcc 9 及以上使用 clang 时还会追加-Wno-errorshadow -Wno-errorunused-but-set-variable随后统一再补-Wno-unused-variable -Wno-unused-function——这正是为了压制新版编译器在 rocksdb 6.3.6 源码上产生的历史性警告。若使用仓库默认构建脚本上述参数已内置若手动编译 rocksdb 遇到同类报错可参照该函数自行追加-Wno-error...。七、ARM 版本编译arm64CubeFS 支持在 x86 开发机上交叉编译 ARM 版本。根目录 build.sh 提供了三种模式arm64_gcc9配合 Ubuntu focal 的 gcc-9-aarch64 交叉工具链、arm64_gcc4配合 gcc-4.9-aarch64 工具链支持 CentOS 7、arm64等价于arm64_gcc4并会在编译前通过get_rocksdb_compress_dep拉取 zlib、bzip2、zstd、lz4 的压缩依赖。7.1 设置环境变量并编译编译 ARM 版本前首先修改环境变量export CPUTYPEarm64_gcc4确认环境变量正确后编译对应模块或全量编译。以编译 libsdk 为例在 cubefs 目录下执行make libsdk该命令会先后触发build_libsdkpre产出libcfs.so对应 build/build.sh 中CGO_ENABLED1 go build -buildmode c-shared与build_libsdk将libcfs.so复制进java/src/main/resources/后执行mvn clean package打包 jar见 build/build.sh。执行过程中若报缺少某个库按需安装即可常见的有yum install cmake yum install g yum install go yum install maven根据编译环境的实际情况将缺失依赖补齐后再次编译一般即可成功。7.2 可能遇到的错误Java 找不到类定义如果遇到 Java 报「找不到类定义」之类的错误例如下图所示根因Maven 安装目录下lib子目录如/usr/share/maven/lib/缺少对应的 jar 包。通常该目录下的大部分 jar 包是 Java 安装目录下 jar 包的软连接当 Java 版本与 Maven 自带的 jar 集合不匹配时就会缺类。此时有两种解决办法。方法一软连接 Java 目录中的同类 jar到 Java 安装目录下根据报错中缺失的类名找到相似的 jar 包然后软连接到 Maven 的lib目录下。例如报错涉及FailureAccess类时在/usr/share/java/guava/目录下可以找到failureaccess.jar将其软连接到/usr/share/maven/lib/下即可ln -s /usr/share/java/guava/failureaccess.jar /usr/share/maven/lib/failureaccess.jar方法二从 Maven 中央仓库下载缺失 jar在 Maven 中央仓库mvnrepository.com中搜索报错中的关键类名找到包含该报错类的 jar 包后下载将其放入 Maven 库目录/usr/share/maven/lib/下即可cp 下载的jar包 /usr/share/maven/lib/完成后再执行make libsdkJava SDK 打包环节即可通过。八、总结与排错速查CubeFS 的编译故障绝大多数集中在C 依赖rocksdb 及其压缩库的探测、编译与链接三个环节本文涉及的排错可以归纳为一张速查表报错特征根因首选处理本机编译通过、其他机器无法启动动态库依赖缺失 / 非可移植编译PORTABLE1 make static_lib重编 rocksdbldd查缺并安装ldconfig刷新ZSTD_versionNumber未定义zstd 探测失败或未显式指定CGO_LDFLAGS指定-lzstd或删除探测脚本片段改为手工-DZSTDrocksdb/c.h: no such file or directory头文件缺失或环境变量未导入确认build/include/rocksdb/c.h存在后source env.sh否则make dist-clean重编cannot find -lbz2/cannot find -lz缺系统开发包安装bzip2-devel(≥1.0.6) /zlib-devel(≥1.2.7) 并ldconfigcc1plus: all warnings being treated as errors新 gcc 将警告视为错误blobstore 设DISABLE_WARNING_AS_ERRORtrue根目录设CXXFLAGS-Wno-errorxxxARM 编译缺 Java 类Maven lib 目录缺 jar软连接 Java 目录 jar或从 Maven 仓库下载放入/usr/share/maven/lib/编译链路涉及的具体构建参数、依赖版本与函数实现均可在 build/build.sh、build.sh、build/cgo_env.sh 及 Makefile 中找到对应代码佐证按上述步骤逐项排查即可让 CubeFS 在 x86 与 ARM 平台上稳定产出可部署的二进制。赞分享存储分布式文件系统对象存储云原生【免费下载链接】cubefscloud-native distributed storage项目地址https://gitcode.com/gh_mirrors/cu/cubefs点击查看免费下载相关推荐KOReader编译错误排查终极指南10个常见交叉编译问题解决方案KOReader编译错误排查终极指南10个常见交叉编译问题解决方案 KOReader是一款功能强大的电子书阅读器应用支持PDF、DjVu、EPUB、FB2等桌面应用跨平台嵌入式lz4/lz4交叉编译工具链从x86到ARM的完整指南lz4/lz4交叉编译工具链从x86到ARM的完整指南 LZ4是一款极速的无损压缩算法提供超过500MB/s每核心的压缩速度解压速度可达数GB/s。在嵌入存储系统编程radare2 Windows 原生构建指南从 Meson/Ninja 编译到静态 Blob 与交叉编译radare2 Windows 原生构建指南从 Meson/Ninja 编译到静态 Blob 与交叉编译 导读 本文以 doc/windows.md http逆向工程网络安全上一篇radix-vueReka UISwitch 组件完全指南SwitchRoot 属性、事件与插槽详解下一篇revm-ee-tests 集成测试指南基于快照机制验证 revm 与 op-revm 的 OP Stack 执行语义创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考