今天项目上遇到一个奇葩的问题

运行程序，报错

(lldb) p (char*)dlerror()

warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.

(char *) $0 = 0x0000000147e218c9 "dlopen(/Users/conanchen/client-delivery/Output/MAC64/Release/Fusion360.app/Contents/Libraries/Applications/Fusion/NaFusionUI10.dylib, 0x0001): Symbol not found: __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE\n Referenced from: /Users/conanchen/client-delivery/Output/MAC64/Release/Libraries/Applications/Fusion/NaFusionUI10.dylib\n Expected in: /Users/conanchen/client-delivery/Output/MAC64/Release/Frameworks/AIRMAX/libContentService.dylib"

奇怪的是这货竟然可以编译过，怎么可能运行的时候找不到这个Symbol呢，让我怀疑人生，还以为发现了编译器的Bug。

conanchen@ConanChen ~ % c++filt __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE

typeinfo for Autodesk::ContentServiceUI::ISearchBox

这个是个typeinfo。我开始想typeinfo是不是有什么特别。不懂的问题太多的时候，思路就混乱。

想从链接的时候找问题，先需要看看到底提供了哪些方法，确定一下是不是没有这个symbol。昨天命令没找到。

今天早上，重新运行一下。

conanchen@ConanChen ~ % nm -nm /Users/conanchen/client-delivery/3P/AIRMAX/NU.FY23_2022.07.12/MAC64_universal_rpath/Frameworks/Release/AIRMAX/libContentServiceUI.dylib | grep __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE

0000000000004198 (__DATA_CONST,__const) external __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE

不是明明有吗？

昨天运行的是

conanchen@ConanChen ~ % nm -nm /Users/conanchen/client-delivery/3P/AIRMAX/NU.FY23_2022.07.12/MAC64_universal_rpath/Frameworks/Release/AIRMAX/libContentService.dylib | grep __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE

仔细对一下发现，一个是libContentService另一个是libContentServiceUI。奇怪了，报错说在libContentService里找不到，其实它是在libContentServiceUI里，难道这个也会错？还会跑偏？记录库的序号可能错，偏了1个？

不相信库，就是不相信计算机本身，库错的概率远低于你自己。

(lldb) image list | grep libContentService.dylib

[ 0] 8B48E1B3-5ADD-3981-A5DB-29B10BFD70B6 0x0000000102b5c000 /Users/conanchen/client-delivery/Output/MAC64/Release/Fusion360.app/Contents/Frameworks/AIRMAX/libContentService.dylib

(lldb) image list | grep libContentServiceUI.dylib

error: the target has no matching modules

发现只加载了libContentService 而没有libContentServiceUI。

突然想到会不会是ID有问题，于是

conanchen@ConanChen ~ % otool -D -arch arm64 /Users/conanchen/client-delivery/Output/MAC64/Release/Frameworks/AIRMAX/libContentServiceUI.dylib

/Users/conanchen/client-delivery/Output/MAC64/Release/Frameworks/AIRMAX/libContentServiceUI.dylib:

@rpath/AIRMAX/libContentService.dylib

还果然是它。所以问题在于，编译的时候，它从libContentServiceUI.dylib里找到了方法，但是当生成二进制文件的时候，它不会写物理硬盘上的文件名。而会用它的ID来指向，这个Case很小众，明明是libContentServiceUI，它的ID却是libContentService。所以明明Symbol在B里，它却找的A，同时上面的加载也可以看到，它加载了libContentService而没有加载libContentServiceUI。

而这个ID是怎么产生的呢，是我自己在改Rpath的时候，发现ID也要改，所以拷贝来拷贝去，把B指向了A。始作俑者乃是本人自己。自己坑了自己。给自己弄了个火焰山。