ios - 使用 lipo 将 iOS .dylib 合并到框架中会破坏位码重新编译

Question

我正在尝试从 .dylib 手动构建动态 iOS 框架文件。二进制文件是用 cmake 和 xcodebuild 创建的，并产生两个 .dylib文件，其中一个包含 armv7 , armv7s和 arm64和另一个 x86_64和 i386架构。库使用 -fembed-bitcode parameter 编译一切顺利。

.dylib 文件然后与下一个命令合并:

lipo -create lib_arm.dylib lib_i386.dylib -output MyFramework

然后通过将 lipo 命令的输出复制到以下位置来创建框架:

MyFramework.framework/MyFramework

标题和 Info.plist手动生成并添加到框架中。

然后这个框架通过 CocoaPods 作为 vendored_framework 安装到应用程序中。 .众所周知，CocoaPods 将从任何胖二进制文件中剥离 i386/x86_64 库，用于 App Store 分发。

应用程序构建、运行、存档并成功上传到 App Store。

但是，由于启用了 Bitcode，App Store 将处理 .ipa，并使用 bitcode 重新编译，这就是它失败的地方，我从 App Store 收到一封电子邮件，说它处理失败。按照说明，我可以通过导出为 Ad-Hoc 分发并重新编译位码来在本地重现错误。我收到的错误是这样的:

ipatool failed with an exception: #<Errno::ENOENT: No such file or directory - /lib_arm.dylib>\n

所以很明显在重新编译期间，仍然有一个引用或某处 lib_arm.dylib ，即使它被合并到一个胖 dylib Mach-O 通用二进制文件( file 下面合并的 dylib 二进制文件的输出):

>> file MyFramework
MyFramework: Mach-O universal binary with 5 architectures: [x86_64: Mach-O 64-bit dynamically linked shared library x86_64] [i386] [arm_v7] [arm_v7s] [arm64]
MyFramework (for architecture x86_64):  Mach-O 64-bit dynamically linked shared library x86_64
MyFramework (for architecture i386):    Mach-O dynamically linked shared library i386
MyFramework (for architecture armv7):   Mach-O dynamically linked shared library arm_v7
MyFramework (for architecture armv7s):  Mach-O dynamically linked shared library arm_v7s
MyFramework (for architecture arm64):   Mach-O 64-bit dynamically linked shared library arm64

这几乎是我的编译器/链接器知识超出范围的地方。
所以我的问题是:

我哪里出错了？也许位码应该以不同的方式编译？或者也许我正在使用 lipo以错误的方式？

谢谢!

Answer 1

使用 otool -l 检查创建的胖二进制文件的加载命令后命令，我意识到使用 lipo本身不会改变LC_ID_DYLIB在二进制文件中，它将重用第一个提供的库中的一个。使用 install_name_tool更改 id 以更正框架之一(包括 @rpath 用于 iOS 动态框架)修复了错误。

install_name_tool -id @rpath/MyFramework.framework/MyFramework MyFramework

确保包含完整的二进制路径以及 .framework目录。