Xcode 10 无法归档项目
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/52389664/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Xcode 10 not being able to archive project
提问by nbloqs
I'm trying to upload a new version of an app that is already in the AppStore. Previous version was uploaded using Xcode 9.4. But now Xcode 10 will be required in order to get approval.
我正在尝试上传 AppStore 中已有的应用程序的新版本。以前的版本是使用 Xcode 9.4 上传的。但是现在需要 Xcode 10 才能获得批准。
Sadly, Xcode is not being able to archive the project, so I'm getting stuck on the first step, not even being able to generate the binary for submission.
遗憾的是，Xcode无法存档项目，所以我在第一步被卡住了，甚至无法生成要提交的二进制文件。
There is no error: According to Xcode, our archiving process has more than 2000 tasks, and is just gets stuck in arbitrary task (always the same). Xcode does not crash, does not show an error and does not complain. It just can't pass that task and the IDE stays there for ever.
没有错误：根据 Xcode，我们的归档过程有 2000 多个任务，并且只是卡在任意任务中（始终相同）。Xcode 不会崩溃，不会显示错误，也不会抱怨。它只是无法通过该任务，而 IDE 将永远留在那里。
We tried it in different machines and also tried two versions: the previous version of the app (that can be archived with Xcode 9.4) and a new version, successfully migrated to Swift 4.2.
我们在不同的机器上试过，也试过两个版本：之前版本的app（可以用Xcode 9.4存档）和新版本，成功迁移到Swift 4.2。
UPDATE:
更新：
- Legacy building system does not work either.
- Build for a Generic iOS Devicealso get stuck (not just archiving), but the software compiles and works on the simulator.
- Tried to compile the non-migrated version selecting Swift 4 (instead of 4.2) and same results.
- Played with optimization levels, whole vs. incremental compilation, etc., and always the same results.
- In Xcode 9.4 it builds for Generic iOS Devicenicely without changing anything.
- 传统建筑系统也不起作用。
- 为通用 iOS 设备构建也会卡住（不仅仅是存档），但软件可以编译并在模拟器上运行。
- 尝试编译选择 Swift 4（而不是 4.2）的非迁移版本，结果相同。
- 使用优化级别、整体编译与增量编译等，结果始终相同。
- 在 Xcode 9.4 中，它很好地为通用 iOS 设备构建，无需更改任何内容。
回答by LexTang
Finally, I removed "armv7" from "Valid Architectures" of project build settings. It archived! This means iPhone 4S is not compatible anymore. But, I don't think Apple will deprecate 4S in this way. By diving into the logs, I found that it stucks in creating dSYM symbols.
最后，我从项目构建设置的“有效架构”中删除了“armv7”。存档了！这意味着 iPhone 4S 不再兼容。但是，我不认为苹果会以这种方式弃用 4S。通过深入研究日志，我发现它坚持创建 dSYM 符号。
[17:15:49]: ? Generating 'ZUS_INHOUSE_DEV.app.dSYM'
[17:16:15]: ?
[17:16:15]: ? (arm64) could not find object file symbol for symbol _lum_convert
[17:16:15]: ? (arm64) could not find object file symbol for symbol _ff_init_desc_hscale
[17:16:15]: ? (arm64) could not find object file symbol for symbol _lum_h_scale
[17:16:15]: ? (arm64) could not find object file symbol for symbol _ff_init_desc_cfmt_convert
[17:16:15]: ?
[17:16:15]: ? (arm64) could not find object file symbol for symbol _ff_init_desc_chscale
[17:16:15]: ? (arm64) could not find object file symbol for symbol _chr_h_scale
[17:16:15]: ? (arm64) could not find object file symbol for symbol _ff_init_desc_no_chr
[17:16:15]: ? (arm64) could not find object file symbol for symbol _no_chr_scale
[17:16:30]: ? (arm64) could not find object file symbol for symbol _vlc_entry__audio_filter_libscaletempo_pitch
[17:16:30]: ?
[17:16:30]: ?
[17:16:30]: ?
[17:16:30]: ?
[17:16:30]: ?
[17:16:30]: ?
[17:16:30]: ? (arm64) failed to insert symbol '_best_overlap_offset_float' in the debug map.
Thus, I guess, another workaround is change "Debug Infomation Format" from "DWARF with dSYM File" to "DWARF".
因此，我想，另一种解决方法是将“调试信息格式”从“带有 dSYM 文件的 DWARF”更改为“DWARF”。
回答by Jon C
We were able to get it to Archive with DSYM by removing optimizations for Swift Compile in the build settings.
通过在构建设置中删除对 Swift Compile 的优化，我们能够使用 DSYM 将其存档。
Build Settings -> Swift Compiler - Code Generation -> Release
构建设置 -> Swift 编译器 - 代码生成 -> 发布
set to "No Optimizations"
设置为“无优化”
Original fix suggested by JacobJ84 on Apple forum: https://forums.developer.apple.com/thread/115185
JacobJ84 在 Apple 论坛上建议的原始修复程序：https://forums.developer.apple.com/thread/115185
回答by Sergio
Like LexTang hinted, one of the workarounds that works, without need to remove armv7 from valid architectures, is to set "DWARF" for "Debug Information Format". Unfortunately, this way we are loosing option for automated crash symbolication. This way finding cause of crash is much harder, but still not impossible. On following links you can find more info about symbolicating iOS crashes: https://coderwall.com/p/ezdcmg/symbolicating-an-ios-crash-log-without-the-original-dsym-filehttps://www.apteligent.com/technical-resource/symbolicating-an-ios-crash-report
就像 LexTang 暗示的那样，无需从有效架构中删除 armv7 的有效解决方法之一是为“调试信息格式”设置“DWARF”。不幸的是，这样我们就失去了自动崩溃符号化的选项。这种方式找到崩溃的原因要困难得多，但仍然不是不可能。在以下链接，你可以找到有关symbolicating的iOS崩溃的详细信息： https://coderwall.com/p/ezdcmg/symbolicating-an-ios-crash-log-without-the-original-dsym-file的https：// WWW。 apteligent.com/technical-resource/symbolicating-an-ios-crash-report
