5

我正在从 iOS 的源代码构建一个动态框架，并启用了位码（使用cmake和xcodebuild）。我使用lipoandinstall_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 并按照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它保持原样。

我的问题仍然存在：

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

谢谢！

4

2 回答 2

3

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

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

于 2017-01-14T05:49:23.117 回答
1

我遇到了完全相同的问题。接受的答案让我很接近，但是设置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)
于 2017-09-21T10:48:00.430 回答