为什么从位码重新编译会导致我无法在Xcode ad hoc版本中进行符号化，并且如何解决？

Question

为什么从位码重新编译会导致我无法在Xcode ad hoc版本中进行符号化，并且如何解决？

11

这让我烦恼了很久，但最终我发现，在将我的应用程序导出进行adhoc部署时，位码编译选项导致我的调试符号文件（dSYM）和应用程序UUID不匹配，这意味着我无法解析任何崩溃日志。

关闭该选项可以解决此问题，但是否有办法在保持选项开启的情况下修复它？我阅读了该选项的提示，它说商店使用此方法。现在我还能从应用商店读取崩溃日志吗，还是只是本地问题？

以下是在此Xcode版本之前的旧版本中获取的内容：

dwarfdump --uuid app
DD25E6C9-... (armv7)
29F74B2E-... (arm64)

dwarfdump --uuid app.dsym
DD25E6C9... (armv7)
29F74B2E... (arm64)

好的。现在开启了位码：

dwarfdump --uuid app
E7D2BE71-... (armv7)
5C871FD7-... (arm64)

dwarfdump --uuid app.dsym
BC93BCF5-... (armv7)
3312658C... (arm64)

显然它不会进行符号化。我已经尝试关闭选项，并且匹配成功了。这是Xcode没有为新的位码构建重新生成符号的问题吗？为什么默认情况下会打开它而不警告您有关崩溃日志的信息？

- kmm3

在Xcode的组织器中，有一个“下载dSYMs”的选项，应该会为苹果构建的xcarchive下载dSYMs。然而，对于我来说，二进制文件的dSYM仍然丢失了，也许你会更幸运。 - OpenUserX03

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dmitry Fink · Accepted Answer

当启用位码时，XCode归档过程会生成以下内容： 1.本机的arm64或armv7代码 2.位码 3.dSYM文件（与本机代码的UUID匹配）

当您生成ad-hoc分发并启用“位码编译”选项时，XCode也会将位码重新编译为本机代码，这通常会导致arm64和armv7部分的UUID不同。原始的app.dSYM没有被修改（因此不匹配新的二进制文件），而是在相同的xcarchive文件夹中生成新的dSYMs，它们的形式为“E2015333-1220-391E-928C-04C32A179EC9.dSYM”，并匹配新编译的二进制文件的实际UUID。

故事并不总是就此结束，这些新的dSYM文件可能会被混淆（即具有__hidden#232434而不是实际符号名称）。解密它们的映射也存储在xcarchive文件夹中的名为“BCSymbolMaps”的文件夹中。

要解密这样的dSYM，可以使用以下命令：

dsymutil --symbol-map <bcSymbol-file> <obfuscated-dsym-file>