重新编译 Bitcode 更改 LC_ID_DYLIB

Question

我正在为 iOS 启用位码（使用 cmake 和 xcodebuild）从源构建一个动态框架。我使用 lipo 和 install_name_tool 制作胖二进制文件并更新 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

查看 LC_ID_DYLIB 的 otool -l 输出显示：

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 并按照 Technical Note TN2432 中的建议启用 "Rebuild from 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 是不正确的，这是在制作胖二进制文件之前最初构建框架的位置的绝对路径。这在 Rebuild from Bitcode 步骤中被替换，但我不知道为什么甚至这个路径存储在现有 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 保持原样。

我的问题仍然存在：

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

谢谢！

Answer 1

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

就我而言，我正在使用 cmake 构建框架，它将此信息添加到 linker flags 中。配置 INSTALL_NAME_DIR 和 BUILD_WITH_INSTALL_RPATH 并使用 @rpath 有效地解决了这个问题，并且不再需要 install_name_tool。

Answer 2

我遇到了完全相同的问题。接受的答案让我很接近，但是单独设置 INSTALL_NAME_DIR 参数并不能解决它，因为它不允许您将传递给链接器的完整值设置为 install_name （仅目录，如您所料)。

相反，我设置了 XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME，它一次性覆盖了完整的值。显然这只适用于 CMake 中的 XCode 生成器，但这对我想要的来说很好。总而言之，我的这个框架的 CMake 文件现在包含：

set_target_properties(${LIBRARY_NAME} PROPERTIES XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME "@rpath/${LIBRARY_NAME}.framework/${LIBRARY_NAME}")
set_target_properties(${LIBRARY_NAME} PROPERTIES BUILD_WITH_INSTALL_RPATH 1)

重新编译 Bitcode 更改 LC_ID_DYLIB

Recompilation with Bitcode changes LC_ID_DYLIB

frameworks

mach-o

dylib

otool

ios