如何在 Xcode 4 中使用 dylib 文件创建工作框架 [英] How do I create a working framework with dylib files in Xcode 4
问题描述
我在 Xcode 中创建了一个新的 cocoa 框架,删除了它一开始包含的所有库和文件,除了支持文件.
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.
.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/中.如果您还没有这样做,请选择 Project > New Build Phase > New Copy Files Build Phase.将 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/添加
)而不是旧的 @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
可用作加载路径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屋!