我详细的说明一下：

这个问题在 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.

有没有可能这就是一个双面 XX 的岗位，为的就是泄露点自己的情报，套取点别人的情报。只是玩脱了，不受控了。

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

看起来是 macOS 的 bug

集资做个杀软，通过微软认证后就摆烂

为什么不升级 6.0 ？有什么让人不爽的功能吗？

西门子 ME45

如果没有领导的约束就采购 C86 。就算业务系统是 java 的，还要考虑是否用了 jni 。
C86 还有一个好处就是可以用各种虚拟化平台。

@DefoliationM 是国产 arm CPU 性能垃圾

5ysnUWBsqxKn2YQd1KEaKyLD58Guga66NGhk8zx2M3FN

Thanks!

牛！点赞！

早些年在 macOS 上用拼音输入法会卡顿，所以用了鼠须管。可是现在 macOS 自带的拼音输入法挺好用的啊

完全作为投屏设备在用，小孩上网课的时候把 iPad 投到电视上

你们不要论断人，免得你们被论断。 因为你们怎样论断人，也必怎样被论断；你们用什么量器量给人，也必用什么量器量给你们。

5ysnUWBsqxKn2YQd1KEaKyLD58Guga66NGhk8zx2M3FN

谢谢大佬

做小的、可控的，能产生价值的(回馈到工作中，or 帮个人赚钱)，这样才能产生正循环。

除了 Studio Display 不要选第三方的。看到一个 B 站的 UP 主吐槽，某个第三方的 5K 显示器，亮度很不准，显示器看不出过曝，也看不出欠曝……只宣传颜色准。

凑热闹

WAGMI