常识决定效率

这周帮同事解决了一个编译问题，如果不是我“多管闲事”，这个问题可能要以重装系统的方式处理了。

这一两年解决的类似疑难杂症其实挺多，大多有着不同的表象和相同的本质。如果想要总结下，为什么最终都是我发现了原因，我觉得最重要的一点就是：我掌握了解决此类问题的必要的常识。

回到问题本身，大致背景是我们最近重构了工程的构建方式，三方库统一由VCPKG管理。开始推广后，发现一位同事在最后链接阶段会报一个错误：harfbuzz里面的符号全部找不到。补充情况如下：

1. 大部分人用的是iMac台式机，而该同事用的是M1，也就是ARM架构
2. 另一个同事用M1是可以的（话说为什么没命中编译缓存）

周围人看了一圈，重试了几次，发现均无法解决，就去吃饭并说只能重装系统了。

吃完饭回来，我简单了解情况后，表示可以排查下。

首先，既然报错是符号找不到，就用nm看看libharfbuzz.a里面是否确实没符号，结果是有的。

这时，就要看看libharfbuzz.a的架构了，结果是x86_64的，这就有问题了，其他库都是arm的，而且宿主也确实是arm。

该同事说，自己之前为了兼容一些x86_64的应用，确实打开了Rosetta 2，但iTerm并没有开启。

那就继续分harfbuzz的构建日志，发现构建系统认为Host的架构是x86_64的。再结合harfbuzz的源码，发现这个库本身是使用meson进行构建的。

而粗糙了解后，又知道了meson其实是基于Python的，而该同事的Python恰好安装的是x86_64架构的。

这下就完全说得通了。卸载重装Python后，harfbuzz也就正常了。

其实在此之前，对于Rosetta、Meson、Harfbuzz这些，我也并没有什么了触怒。

但对于C++的常见链接错误及其排查思路，我是门清的。所以，基于一些正确的“常识”，逐步推理出上一个环节的问题，也就找到了最终的答案。

其他同事既没有相关经验，对于nm/objdump等相关工具也不太清楚，自然很难找到切入点。

有时候，问题与答案之间就隔着一层窗户纸，像GPT这样的大模型工具是非常擅长突破这些限制的，所以我经常用GPT启发我排查问题。

为了不被GPT取代，以后要注意多深度思考一些问题，特别是一些领域，问题和答案之前隔着几层水泥墙的，才是人之价值所在。