使用位码更改 LC_ID_DYLIB 重新编译

Question

我正在从启用位码的 iOS 源代码构建一个动态框架（使用cmake和xcodebuild）。我使用lipo和install_name_tool制作一个胖二进制文件并 update LC_ID_DYLIB，以便正确加载二进制文件。当我归档应用程序时，框架已正确签名并与应用程序一起打包。这是以下的输出file：

MyFramework: Mach-O universal binary with 3 architectures: [arm_v7: Mach-O dynamically linked shared library arm_v7] [arm_v7s] [arm64]
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

查看otool -l输出LC_ID_DYLIB显示：

Load command 4
          cmd LC_ID_DYLIB
      cmdsize 64
         name @rpath/MyFramework.framework/MyFramework (offset 24)
   time stamp 1 Thu Jan  1 01:00:01 1970
      current version 1.0.0
compatibility version 1.0.0

这一切似乎都是正确的。如果我将此存档上传到 App Store，它就会被正确上传和处理。从App Store运行它后，由于加载动态框架，它在启动后立即崩溃。众所周知，应用程序是从 App Store 上的 Bitcode 重新编译的，因此我通过导出为 Ad-Hoc 并按照技术说明 TN2432中的建议启用“从 Bitcode 重建”选项来进行模拟。检查 .ipa （启动后也崩溃了）和有问题的框架，这是以下输出otool -l：

Load command 3
          cmd LC_ID_DYLIB
      cmdsize 128
         name /Users/legoless/Downloads/ios/build/build-iphoneos/lib/Release/MyFramework_ios.framework/MyFramework_ios (offset 24)
   time stamp 1 Thu Jan  1 01:00:01 1970
      current version 1.0.0
compatibility version 1.0.0

显然LC_ID_DYLIB这个库的 是不正确的，这是在制作胖二进制文件之前最初构建框架的位置的绝对路径。这在“从位码重建”步骤中被替换，但我不知道为什么甚至不知道该路径存储在现有Mach-O文件中的位置。我使用otool和objdump工具尝试在 Mach-O 二进制文件中查找引用，但没有成功。

实际上，另一个框架依赖于这个框架，这是目标框架的加载命令：

Load command 14
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name @rpath/MyFramework.framework/MyFramework (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1.0.0
compatibility version 1.0.0

在使用 Bitcode 重建之后，此处的引用也发生了更改：

Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 128
         name /Users/legoless/Downloads/ios/build/build-iphoneos/lib/Release/MyFramework_ios.framework/MyFramework_ios (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1.0.0
compatibility version 1.0.0

这种情况仅发生在相关框架中，而不会发生在其他框架中，@rpath保持原样。

我的问题仍然存在：

这个绝对路径引用存储在哪里？以及如何删除它，以便 Rebuild from Bitcode 不再影响它？

谢谢你！

Answer 1

对这个问题进行详细调查后发现， Mach-O 文件中包含位码的.xar存档存储了大量信息，包括链接器标志。此信息存储在存档的目录中，并用于在位码重新编译时重新编译/重新链接库。

就我而言，我使用cmake构建框架，并将这些信息添加到链接器标志中。配置INSTALL_NAME_DIR和BUILD_WITH_INSTALL_RPATH使用@rpath有效地解决了这个问题，并且install_name_tool不再需要了。