为 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(在转换时)才会出现。

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

wanglili19860813 回答:为 ARM 编译时使用破坏 zksync

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

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

向库作者报告一些错误。

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

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

本文链接:https://www.f2er.com/613728.html

大家都在问