为 ARM 编译时使用破坏 zksync

如何解决为 ARM 编译时使用破坏 zksync

这是一个复杂而困难的问题，但我会尽我所能分解它。归结为我何时为 ARM64 编译 Rust 项目（目标是在 rasp pi 4 上运行）。

大多数库编译 (704 / 740)，但在编译 zksync 目录时会在编译期间中断。 golem 的 yagna client 是我正在编译的，我正在使用

目标 - target.arm-unkNown-linux-musleabi 链接器 - arm-linux-gnueabihf-ld

我很想听听解决方案的想法，或者我做错了什么，以便我可以在 ARM 上运行这个项目。 我得到的错误代码是

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

除其他错误外，所有错误都与转换整数时的位差异有关。这让我怀疑 usize 是罪魁祸首，因为它基于 cpu 架构的大小，这可以解释 ARM 编译把它搞砸了，直到你必须处理 int（在转换时）才会出现。

如果您需要更多信息，请告诉我，尽力将问题封装起来

解决方法

stat是一个Statvfs结构，Statvfs::blocks_available()的返回类型是fsblkcnt_t，Statvfs::fragment_size()的返回类型是c_ulong。这两种类型在 libc 包中定义，它是围绕低级 C OS 调用的纸薄包装。这些类型等效于特定于操作系统的 *.h 文件中的 C 类型。类型的大小因平台而异。

您正在编译的库似乎有一些关于这些大小及其算术兼容性的假设。

向库作者报告一些错误。

如果您愿意自己修补库，那么您应该首先调查您平台的 libc 包并检查您所看到的错误所涉及的所有类型的定义。然后修正算术表达式，使类型兼容且不会溢出。

我认为 Rust 的类型系统不够智能，无法支持一个代码体来处理所有潜在的类型大小组合，既安全（没有溢出或截断）又有效（没有不必要地将所有内容强制转换为 u128）。可能需要特定于平台的补丁。