为ARM编译时使用大小中断zksync

Question

这是一个复杂而困难的问题，但我将尽我所能将其分解。归根结底，当我为ARM64编译一个rust项目时(目标是在rasp pi 4上运行)。

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

target -target.arm-未知-linux-musleabi链接器- arm-linux-gnueabihf-ld

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

​

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

​

在其他错误中，转换整数时所有错误都围绕着位差异。这导致我怀疑usize是罪魁祸首，因为它的大小基于CPU架构，这可以解释ARM编译把它搞得一团糟，直到你必须处理int (在转换时)才显示出来。

如果您需要更多的信息，请让我知道，我已经尽了最大的努力来概括这个问题

Answer 1

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

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

向库作者提交的一些错误报告将是正确的。

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

我认为Rust的类型系统不够智能，不足以支持处理所有可能的字体大小组合的代码体，既安全(没有溢出或截断)又有效(没有不必要地将所有内容都转换为u128)。可能需要特定于平台的补丁。