两台电脑一台用 GLM v4.6 打前阵，在遇到解决不了的问题(汇报干完了，实际上都编译不了)后，commit + push, 另一台电脑 pull 后用官方的 Claude Code 来收尾。

生日快乐

@jsph bazel 是理想，小团队不现实

依然使用 cmake + vcpkg ，也可以 cmake + ExternalProject_Add

如果你想要你的程序不只是兼容特定的 Linux 发行版，你就不要使用 Linux 包管理器安装的-dev 或-devel 包。这一点上商业软件为了维护更少的包，基本上会采取这种做法，和 Linux 发行版里面自带软件的做法相反。

想要兼容更多的 Linux 发行版，你就要考虑编译环境的 glibc 版本（想要兼容更老的版本，就意味着不能使用 C++更新的标准)

对于上了年纪的人来看，这简直是炫耀啊

如果硬盘 IO 不高，CPU 负载也低，应该没那么耗电，大部分时候可以控制在 35W 以内。

yu7 完全不要考虑。缺乏造车经验，设计优先于安全和功能。它的进步需要时间。

不折腾不是群晖+raid1 吗？

加密算法不一样，性能数据就没有比较的意义

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

生日快乐

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

自从 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