如何在Xcode 4中使用dylib文件创建工作框架 [英] How do I create a working framework with dylib files in Xcode 4

问题描述

我已经在Xcode中创建了一个新的可可框架，删除了它开头包含的所有库和文件(支持文件除外).

I have created a new cocoa framework in Xcode, removed all the libraries and files it includes at the beginning except the supporting files.

我有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来编译公共头文件.项目构建没有问题，但是在框架中没有dylib文件，当我将框架拖放到另一个项目时，它说找不到dylib文件.

in build phases I add add.c to compile sources and add.h to compile headers public. The project build without a problem but in the framework there is no dylib file and when I drag and drop the framework to another project it says that dylib file could not be found.

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文件保留在其中?

How can I make a simple framework and keep dylib files inside it ?

推荐答案

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

I think you're misunderstanding the error message.

A .framework可以用作动态库，但在.framework文件夹内不会有任何具有实际.dylib文件扩展名的Mach-O可加载目标文件.

A .framework works as a dynamic library, but there won't be any Mach-O loadable object file with an actual .dylib filename extension inside the .framework folder.

在运行时，可能会从动态链接库加载器dyld中获取该错误消息的原因有两个.首先是您忘记了在构建过程中将.frameworks复制到已构建的应用程序包中.尽管可以将它们复制到应用程序捆绑包内的任何位置，但传统位置在AppName.app/Contents/Frameworks/中.如果尚未执行此操作，请选择项目">新建构建阶段">新建副本文件构建阶段".如下图所示，将Destination弹出窗口更改为Frameworks.

There are a couple of reasons you might be getting that error message from dyld, the dynamic link library loader, at runtime. The first is that you forgot to copy the .frameworks into the built application bundle during the build process. While they can be copied to about any location inside the app bundle, the traditional place is in AppName.app/Contents/Frameworks/. If you haven't done so already, choose Project > New Build Phase > New Copy Files Build Phase. Change the Destination popup to Frameworks like in the image below.

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

You'll then drag the icon of the framework into the folder so that it's copied during the build process.

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

The second and more likely reason the framework can't be found at runtime is that you haven't specified any runpath search paths for your main executable. (This is needed, because, as we saw from your error message, your framework was built using the newer @rpath/ style install name (@rpath/add.framework/Versions/A/add) rather than the older @executable_path/ or @loader_path/ styles).

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

Provided you copy the custom frameworks to the location mentioned above, you'd add a runpath search path entry of @loader_path/../Frameworks, like shown in the image below:

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

The following excerpt that explains how dynamic libraries are found at runtime is from the manpage of dyld:

动态库加载

与许多其他操作系统不同，达尔文无法定位 依赖的动态库通过其叶文件名.相反， 使用了每个dylib的完整路径(例如 /usr/lib/libSystem.B.dylib).但是有时候 路径不合适；例如，可能希望您的二进制文件是 可安装在磁盘上的任何位置.为了支持这一点，有三个 可用作路径前缀的@xxx/变量.在运行时dyld 将动态生成的路径替换为@xxx/前缀.

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/

此变量替换为目录路径 包含该过程的主要可执行文件.这对于 加载嵌入在.app目录中的dylibs/frameworks.如果 主可执行文件位于/some/path/My.app/Contents/MacOS/My 框架dylib文件位于
/some/path/My.app/Contents/Frameworks/Foo.framework/Versions/A/Foo， 然后可以将框架加载路径编码为 @executable_path/../Frameworks/Foo.framework/Versions/A/Foo和 .app目录可以 在文件系统中移动，dyld仍然可以 加载嵌入式框架.

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/

此变量替换为目录路径 包含mach-o二进制文件，其中包含使用以下命令的加载 @loader_path.因此，在每个二进制文件中，@loader_path都解析为 不同的路径，而@executable_path始终解析为 相同的路径. @loader_path可用作a的加载路径 如果最终文件系统是嵌入在插件中的framework/dylib， 插件的位置未知(因此无法使用绝对路径) 或者该插件被多个应用程序使用(因此 @executable_path不能使用).如果插件的mach-o文件位于 /some/path/Myfilter.plugin/Contents/MacOS/Myfilter和一个 框架dylib文件位于 /some/path/Myfilter.plugin/Contents/Frameworks/Foo.framework/Versions/A/Foo， 然后框架加载路径 可以编码为 @loader_path/../Frameworks/Foo.framework/Versions/A/Foo和 Myfilter.plugin目录可能是 在文件系统中移动，dyld仍然可以 加载嵌入式框架.

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维护当前的路径堆栈，称为运行路径 列表.遇到@rpath时，将其替换为每个 运行路径列表中的路径，直到找到可加载的dylib.这 运行路径堆栈是通过LC_RPATH加载命令构建的 导致当前dylib负载的依赖链.你可以 使用-rpath选项向图像添加LC_RPATH加载命令 到ld(1).您甚至可以添加一个LC_RPATH加载命令路径， 以@loader_path/开头，它将在运行中推送一条路径 相对于包含LC_RPATH的图像的路径堆栈. 当您遇到复杂的情况时，使用@rpath最为有用 可以安装的程序和dylib的目录结构 任何地方，但要保持相对位置.这种情况 可以使用@loader_path来实现，但是 dylib可能需要不同的加载路径，因为它的相对路径 在文件系统中的位置是不同的. @rpath的使用 引入了一个简化事物的间接层次.你 在目录结构中选择一个位置作为定位点. 然后，每个dylib都获得一个以@rpath开头的安装路径，然后 是相对于锚点的dylib的路径.每个主要 可执行文件与-rpath @loader_path/zzz链接，其中zzz是 从可执行文件到锚点的路径.在运行时 dyld将其运行路径设置为锚点，然后每个dylib为 找到相对于锚点的位置.

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.

这篇关于如何在Xcode 4中使用dylib文件创建工作框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！