如何在 Xcode 4 中使用 dylib 文件创建工作框架
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/7562793/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How do I create a working framework with dylib files in Xcode 4
提问by user966020
I have created a new cocoa framework in Xcode, removed all the libraries and files it includes at the beginning except the supporting files.
我在 Xcode 中创建了一个新的可可框架,删除了它在开头包含的所有库和文件,除了支持文件。
I have 2 files:
我有2个文件:
add.h
#ifndef add_add_h
#define add_add_h
void add(void);
#endif
and
和
add.c
#include <stdio.h>
#include "add.h"
void add(void)
{
printf("adfding");
}
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.
在构建阶段,我添加 add.c 来编译源代码并添加 add.h 来编译公共头文件。项目构建没有问题,但在框架中没有 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
How can I make a simple framework and keep dylib files inside it ?
如何制作一个简单的框架并将 dylib 文件保存在其中?
回答by NSGod
I think you're misunderstanding the error message.
我认为您误解了错误消息。
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.
A.framework
作为动态库工作,但.dylib
在 .framework 文件夹中不会有任何带有实际文件扩展名的Mach-O 可加载目标文件。
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.
dyld
在运行时,您可能会从动态链接库加载器 中收到该错误消息的原因有多种。首先是您在构建过程中忘记将 .frameworks 复制到构建的应用程序包中。虽然它们可以复制到应用程序包内的任何位置,但传统的位置是在 AppName.app/Contents/Frameworks/ 中。如果您还没有这样做,请选择 Project > New Build Phase > New Copy Files Build Phase。将目标弹出窗口更改为框架,如下图所示。
You'll then drag the icon of the framework into the folder so that it's copied during the build process.
然后将框架的图标拖到文件夹中,以便在构建过程中复制它。
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).
在运行时找不到框架的第二个也是更可能的原因是您没有为主可执行文件指定任何运行路径搜索路径。(这是必要的,因为,正如我们从您的错误信息所看到的,你的框架是使用较新的内置@rpath/
式的安装名称(@rpath/add.framework/Versions/A/add
),而不是旧的@executable_path/
或@loader_path/
样式)。
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:
如果您将自定义框架复制到上述位置,您将添加 的运行路径搜索路径条目@loader_path/../Frameworks
,如下图所示:
The following excerpt that explains how dynamic libraries are found at runtime is from the manpage of dyld
:
以下摘录解释了如何在运行时找到动态库,摘自以下联机帮助页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 runtimedyld
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 anddyld
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 theMyfilter.plugin
directory could be moved around in the file system anddyld
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 theLC_RPATH
load commands in the depencency chain that lead to the current dylib load. You can add anLC_RPATH
load command to an image with the-rpath
option told
(1). You can even add aLC_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 theLC_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
, wherezzz
is the path from the executable to the anchor point. At runtimedyld
sets it run path to be the anchor point, then each dylib is found relative to the anchor point.
动态库加载
与许多其他操作系统不同,Darwin 不通过它们的叶子文件名来定位依赖的动态库。而是使用每个 dylib 的完整路径(例如
/usr/lib/libSystem.B.dylib
)。但有时完整路径并不合适;例如,可能希望您的二进制文件可安装在磁盘的任何位置。为了支持这一点,有三个@xxx/
变量可以用作路径前缀。在运行时dyld
用动态生成的路径替换@xxx/
前缀。
@executable_path/
该变量被替换为包含进程的主要可执行文件的目录的路径。这对于加载嵌入在 .app 目录中的 dylibs/frameworks 很有用。如果主可执行文件在 at
/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
仍然能够加载嵌入式框架。
@loader_path/
该变量被替换为包含 mach-o 二进制文件的目录的路径,该文件包含使用
@loader_path
. 因此,在每个二进制文件中,@loader_path
解析到不同的路径,而@executable_path
总是解析到相同的路径。@loader_path
如果插件的最终文件系统位置未知(因此不能使用绝对路径)或者插件被多个应用程序使用(所以@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
仍然能够加载嵌入式框架。
@rpath/
Dyld 维护一个当前的路径堆栈,称为运行路径列表。当
@rpath
遇到它时,它会替换为运行路径列表中的每个路径,直到找到可加载的 dylib。运行路径堆栈是从LC_RPATH
导致当前 dylib 加载的依赖链中的加载命令构建的。您可以LC_RPATH
使用-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。