为树莓派4编译ARM版Rust项目时zksync依赖触发usize编译错误

当前编译基础场景 #

• 编译对象：Golem生态yagna客户端
• 目标运行设备：树莓派4
• 现有交叉编译配置：目标三元组为arm-unknown-linux-musleabi，指定链接器为arm-linux-gnueabihf-ld
• 编译进度：总计740个依赖库中704个完成编译，构建流程在zksync依赖环节中断

核心报错信息 #

构建中断时触发的核心类型不匹配报错如下：

Ok(stat.blocks_available() as u64 * stat.fragment_size())
^^^^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`

其余报错均为同类整数转换环节的位宽差异类型不匹配，无其他构建异常。

问题根因判定 #

• 该类报错为架构相关的整数位宽不匹配问题，根因与usize类型的位宽特性直接相关：usize位宽完全由目标CPU架构决定，x86_64平台下usize为64位，与u64运算无类型冲突，因此本地x86平台编译无异常。
• 当前使用的32位ARM目标下，usize为32位（等价于u32），未做显式转换直接参与u64类型运算时，就会触发上述类型不匹配提示。

排查与解决路径 #

• 先核对目标三元组是否匹配设备需求：树莓派4的ARMv8芯片原生支持64位用户态，当前使用的arm-unknown-linux-musleabi是32位ARM编译目标，要是没有特殊的32位依赖要求，直接把编译目标换成aarch64-unknown-linux-musl，这批由位宽差导致的类型不匹配报错会直接消失，还能拿到更好的运行性能。
• 如果必须用32位编译目标，就逐一定位zksync依赖里缺类型转换的地方：
  • 对着报错行做显式强转，把参与运算的所有非u64值统一转成u64再计算，比如原来的报错行改成Ok(stat.blocks_available() as u64 * stat.fragment_size() as u64)，所有同类报错按这个逻辑改完就能过编译。
  • 如果这个zksync依赖是从公开crate源拉的，不想直接改cargo缓存里的代码，就在项目根目录的Cargo.toml里配[patch.crates-io]块，把对应依赖指向你本地改好的代码路径，再跑编译就行。
• 最后核对下链接器配置和编译目标是不是对得上：当前选的arm-linux-gnueabihf-ld是适配glibc硬浮点EABI的32位链接器，和arm-unknown-linux-musleabi对应的musl静态编译目标并不完全匹配，要是坚持用musl的32位目标，就得换成对应架构的musl链接器，不然过了编译阶段还可能在链接环节出非预期报错。

内容的提问来源于stack exchange，提问作者Frustrated