除了写小工具外再也不想用 Rust 了

[tinybaby365]

新版本完全不考虑老系统的兼容。在 Windows 上还能靠 YY-Thunks 苟延残喘。在 Linux 下 cargo zigbuild 能搞定依赖的 glibc 版本，但搞不定 aarch64 环境 glibc 缺 API 。

[licolicoli]

有一次想把一个小玩具迁移到 Rust ，结果做完调研发现 Rust 的编译器已经放弃 MIPS 支持了 https://github.com/rust-lang/compiler-team/issues/648 遂放弃，继续用我的 C/Go...

[hingle]

我觉得 Rust 还是很好的。像楼上说的 MIPS ，只是降到 Tier 3 了，并不是不能用。

Rust 的 Win7 支持也是 Tier 3 ，用 nightly -Zbuild-std 就能编译出 Win7 程序。

[lloovve]

快进到 rust 专用芯片，感觉 rust 越走越专了，钻牛角尖。

[clarkethan]

这不是 Rust 独有的问题，凡是依赖 glibc 的语言都会遇到。C/C++ 有 manylinux ，Go 靠静态链接，Swift 用 back-deployment ，Rust 也有 musl 、cargo-zigbuild 、旧环境构建等办法。只是不同生态各有取舍，本质还是 glibc 的兼容策略所致，遇到的时候，确实可能会让新手比较难下手，搞不定的话，建议还是用自己熟悉的并且简易支持对应目标的语言去解决需求

[billzhuang]

@licolicoli Linux 新内核也放弃 MIPS 了

[IamUNICODE]

@billzhuang 感觉国内好多 linux 系统内核都是 mips ，尤其是嵌入式那边的，这就很麻烦了。

[tinybaby365]

@clarkethan C/C++编译器从头文件基本上知道用的 API 是否支持了(是否定义)，不管是 native 编译还是交叉编译环境。Rust 隔了一层，在编译 exe 的时候能发现问题，但在编译 so 的时候就会出现这种情况。

[bli22ard]

golang 的 win7 支持最后版本是 1.20 , 目前 golang 的 latest 版本是 1.25 ，都差不多吧。
zigbuild 不是可以指定 glibc 版本吗， 难道 arm64 ， 指定了 glibc 版本也不行？

[chengYT]

@bli22ard 部分库即使 zigbuild 指定了 glibc 版本还是会打进来高版本 libc 的函数依赖，也可能是我刚开始搞，没搞明白。

[tinybaby365]

我详细的说明一下：

这个问题在 C/C++编译 so 时可能也会遇到，就是 so 依赖某个符号，在链接的时候这个符号找不带，编译器不会报错(ELF 中这个符号是 undefined symbol)(编译 exe 的时候会报错， 很容易发现问题)。在使用这个 so 的时候：如果实际不会调用到这个符号，没有问题；如果调用到这个符号且进程的其他模块有这个符号，没有问题；如果调用到这个符号且进程的其他模块没有这个符号，那就会报错。

使用 C/C++开发，正常情况下(include 头文件, 不 extern)，不会遇到 glibc 的 API 有声明，但链接的时候找不到的情况。正常编译和交叉编译都一样。

现在遇到 Rust 的问题大概是这样的，它相当于是在 C/C++中用 extern 声明了某个 glibc API ，但实际上这个 API 仅在 x86_64 的环境下有，在 aarch64 的环境下是没有的(不要意外，实际情况就是这样)。其他的 glibc API 在 zigbuild 的帮助下可以指定 glibc 的版本链接好，但 aarch64 下面 glibc 没有的 API ，就和 gcc 的表现一样，不报错，实际上是 undefined symbol.