xcode - 如何在 Xcode 4 中使用 dylib 文件创建工作框架

Question

我在 Xcode 中创建了一个新的 cocoa 框架，删除了它在开始时包含的所有库和文件，除了支持文件。

我有 2 个文件:

add.h

#ifndef add_add_h
#define add_add_h

void add(void);

#endif

和

add.c
#include <stdio.h>
#include "add.h"

void add(void)
{
    printf("adfding");

}

在构建阶段，我添加 add.c 来编译源代码和 add.h 来编译公共(public)头文件。项目构建没有问题，但在框架中没有 dylib 文件，当我将框架拖放到另一个项目时，它说找不到 dylib 文件。

dyld: Library not loaded: @rpath/add.framework/Versions/A/add 
  Referenced from: /Users/vjoukov/Desktop/Projects/test/build/Debug/test.app/Contents/MacOS/test
  Reason: image not found

如何制作一个简单的框架并将 dylib 文件保存在其中？

Answer 1

我认为您误解了错误消息。

一个 .framework作为动态库工作，但不会有任何具有实际 .dylib 的 Mach-O 可加载目标文件.framework 文件夹中的文件扩展名。

您可能会收到来自 dyld 的错误消息有几个原因。 ，动态链接库加载器，在运行时。首先是您在构建过程中忘记将 .frameworks 复制到构建的应用程序包中。虽然它们可以复制到应用程序包内的任何位置，但传统的位置是在 AppName.app/Contents/Frameworks/中。如果您还没有这样做，请选择 Project > New Build Phase > New Copy Files Build Phase。将 Destination 弹出窗口更改为 Frameworks，如下图所示。



然后，您将框架的图标拖到文件夹中，以便在构建过程中复制它。



在运行时无法找到该框架的第二个也是更可能的原因是您没有为您的主可执行文件指定任何运行路径搜索路径。 (这是必需的，因为正如我们从您的错误消息中看到的，您的框架是使用较新的 @rpath/ 样式安装名称( @rpath/add.framework/Versions/A/add )而不是较旧的 @executable_path/ 或 @loader_path/ 样式构建的)。

如果您将自定义框架复制到上述位置，您将添加一个运行路径搜索路径条目 @loader_path/../Frameworks ，如下图所示:



以下解释如何在运行时找到动态库的摘录来自 dyld 的联机帮助页。 :

DYNAMIC LIBRARY LOADING

Unlike many other operating systems, Darwin does not locate dependent dynamic libraries via their leaf file name. Instead the full path to each dylib is used (e.g. /usr/lib/libSystem.B.dylib). But there are times when a full path is not appropriate; for instance, may want your binaries to be installable in anywhere on the disk. To support that, there are three @xxx/ variables that can be used as a path prefix. At runtime dyld substitutes a dynamically generated path for the @xxx/ prefix.

@executable_path/

This variable is replaced with the path to the directory containing the main executable for the process. This is useful for loading dylibs/frameworks embedded in a .app directory. If the main executable file is at /some/path/My.app/Contents/MacOS/My and a framework dylib file is at
/some/path/My.app/Contents/Frameworks/Foo.framework/Versions/A/Foo, then the framework load path could be encoded as @executable_path/../Frameworks/Foo.framework/Versions/A/Foo and the .app directory could be moved around in the file system and dyld will still be able to load the embedded framework.

@loader_path/

This variable is replaced with the path to the directory containing the mach-o binary which contains the load command using @loader_path. Thus, in every binary, @loader_path resolves to a different path, whereas @executable_path always resolves to the same path. @loader_path is useful as the load path for a framework/dylib embedded in a plug-in, if the final file system location of the plugin-in unknown (so absolute paths cannot be used) or if the plug-in is used by multiple applications (so @executable_path cannot be used). If the plug-in mach-o file is at /some/path/Myfilter.plugin/Contents/MacOS/Myfilter and a framework dylib file is at /some/path/Myfilter.plugin/Contents/Frameworks/Foo.framework/Versions/A/Foo, then the framework load path could be encoded as @loader_path/../Frameworks/Foo.framework/Versions/A/Foo and the Myfilter.plugin directory could be moved around in the file system and dyld will still be able to load the embedded framework.

@rpath/

Dyld maintains a current stack of paths called the run path list. When @rpath is encountered it is substituted with each path in the run path list until a loadable dylib if found. The run path stack is built from the LC_RPATH load commands in the depencency chain that lead to the current dylib load. You can add an LC_RPATH load command to an image with the -rpath option to ld(1). You can even add a LC_RPATH load command path that starts with @loader_path/, and it will push a path on the run path stack that relative to the image containing the LC_RPATH. The use of @rpath is most useful when you have a complex directory structure of programs and dylibs which can be installed anywhere, but keep their relative positions. This scenario could be implemented using @loader_path, but every client of a dylib could need a different load path because its relative position in the file system is different. The use of @rpath introduces a level of indirection that simplies things. You pick a location in your directory structure as an anchor point. Each dylib then gets an install path that starts with @rpath and is the path to the dylib relative to the anchor point. Each main executable is linked with -rpath @loader_path/zzz, where zzz is the path from the executable to the anchor point. At runtime dyld sets it run path to be the anchor point, then each dylib is found relative to the anchor point.