tinybaby365

常温或者低温储存，在保质期内，蔗糖不会全部水解吧？我觉得至少还有蔗糖风味。

生日快乐

有孩子后就不一样了，孩子是吞金兽

自从 WPS2005 版本开始，保存为*.wps 和*.doc 都是一个格式(基于 CFB)，只是扩展名的区别。

生日快乐！！！

我详细的说明一下：

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