xcode 如何正确设置运行路径、搜索路径和安装名称?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/9798623/
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 to properly set run paths, search paths, and install names?
提问by BigMacAttack
I have a collection of projects that I'm compiling as dynamic libraries. Each of these .dylibs depend on other various .dylibs that I would like to place in various other directories (i.e. some at the executable path, some at the loader path, some at a fixed path).
我有一组正在编译为动态库的项目。这些 .dylib 中的每一个都依赖于我想放置在各种其他目录中的其他各种 .dylib(即一些在可执行路径中,一些在加载器路径中,一些在固定路径中)。
When I run otool -L
on the compiled libraries, I get a list of paths to those dependencies but I have know idea how those paths are being set/determined. They almost appear pseudo random. I've spent hours messing with the "Build Settings" in Xcode to try and change these paths (w/ @rpath, @executable_path, @loader_path, etc.) but I can't seem to change anything (as checked by running otool -L
). I'm not even entirely sure where to add these flags and don't really understand the difference between the following or how to properly use them:
当我otool -L
在编译的库上运行时,我得到了这些依赖项的路径列表,但我知道这些路径是如何设置/确定的。它们几乎是伪随机的。我花了几个小时弄乱 Xcode 中的“构建设置”来尝试更改这些路径(w/@rpath、@executable_path、@loader_path 等),但我似乎无法更改任何内容(通过运行检查otool -L
) . 我什至不完全确定在哪里添加这些标志,也不太了解以下内容之间的区别或如何正确使用它们:
Linking - "Dynamic Library Install Name"
Linking - "Runpath Search Paths"
Linking - "Other Linking Flags"
Search Paths - "Library Search Paths"
链接 - “动态库安装名称”
链接 - “运行路径搜索路径”
链接 - “其他链接标志”
搜索路径 - “库搜索路径”
When I run install_name_tool -change
on the various libraries, I am able to successfully change the run path search paths (again as verified by running otool -L
to confirm).
当我install_name_tool -change
在各种库上运行时,我能够成功更改运行路径搜索路径(再次通过运行otool -L
确认进行验证)。
I'm running Xcode 4.2 and I'm very close to giving up and just using a post-build script that runs install_tool_name to make the changes. But its a kludge hack fix and I'd prefer not to do it.
我正在运行 Xcode 4.2 并且我非常接近放弃并且只使用运行 install_tool_name 的构建后脚本来进行更改。但它是一个杂乱无章的黑客修复,我不想这样做。
Where can I see how the search/run paths for the dylib dependencies are being set?
Anyone have any ideas on what I might be doing wrong?
我在哪里可以看到如何设置 dylib 依赖项的搜索/运行路径?
有人对我可能做错了什么有任何想法吗?
采纳答案by Kurt Revis
Typically, in my dylib's target, I set INSTALL_PATH
aka "Installation Directory" to the prefix I want (e.g. @executable_path/../Frameworks
).
通常,在我的 dylib 目标中,我将INSTALL_PATH
又名“安装目录”设置为我想要的前缀(例如@executable_path/../Frameworks
)。
I leave LD_DYLIB_INSTALL_NAME
aka "Dynamic Library Install Name" set to its default value, which is $(DYLIB_INSTALL_NAME_BASE:standardizepath)/$(EXECUTABLE_PATH)
.
我将LD_DYLIB_INSTALL_NAME
又名“动态库安装名称”设置为其默认值,即$(DYLIB_INSTALL_NAME_BASE:standardizepath)/$(EXECUTABLE_PATH)
.
Xcode expands that based on your target's name, so it might end up being @executable_path/../Frameworks/MyFramework.framework/Versions/A/MyFramework
, for instance.
例如,Xcode 会根据您的目标名称对其进行扩展,因此它最终可能是@executable_path/../Frameworks/MyFramework.framework/Versions/A/MyFramework
。
The important thing to realize is that the install path is built intothe dylib, as part of its build process. Later on, when you link B.dylib that refers to A.dylib, A.dylib's install path is copied intoB.dylib. (That's what otool
is showing you -- those copied install paths.) So it's best to get the correct install path built into the dylib in the first place.
需要意识到的重要一点是,安装路径已内置到dylib 中,作为其构建过程的一部分。稍后,当您链接引用 A.dylib 的 B.dylib 时,A.dylib 的安装路径将复制到B.dylib 中。(这otool
就是向您展示的内容——那些复制的安装路径。)因此,最好首先将正确的安装路径内置到 dylib 中。
Before trying to get all the dylibs working together, check each one individually. Build it, then otool -L
on the built dylib. The first line for each architecture should be what LD_DYLIB_INSTALL_NAME
was showing you.
在尝试让所有 dylib 一起工作之前,请单独检查每个。构建它,然后otool -L
在构建的 dylib 上。每个架构的第一行应该LD_DYLIB_INSTALL_NAME
是向您展示的内容。
Once you have that organized, try to get the dylibs linking against each other. It should be much more straightforward.
一旦你把它组织起来,试着让 dylib 相互链接。它应该更直接。
回答by jww
install_name_tool
is very useful for setting the names and paths. Its especially useful if the program runs its self-tests in the build directory, and then things change during a make install
. In this case, you can use install_name_tool
without the need for a separate build.
install_name_tool
对于设置名称和路径非常有用。如果程序在构建目录中运行自检,然后在make install
. 在这种情况下,您install_name_tool
无需单独构建即可使用。
install_name_tool
is also useful because Apple's LD does not honor rpath
linker options like Linux/GCC does. That is, you need to use a different set of commands to set them.
install_name_tool
也很有用,因为 Apple 的 LDrpath
不像 Linux/GCC 那样支持链接器选项。也就是说,您需要使用一组不同的命令来设置它们。
Here's the man page for it. Its included in its entirety because it discusses other options, like -headerpad_max_install_names
.
这是它的手册页。它完整地包含在内,因为它讨论了其他选项,例如-headerpad_max_install_names
.
INSTALL_NAME_TOOL(1) INSTALL_NAME_TOOL(1)
NAME
install_name_tool - change dynamic shared library install names
SYNOPSIS
install_name_tool [-change old new ] ... [-rpath old new ] ...
[-add_rpath new ] ... [-delete_rpath new ] ... [-id name] file
DESCRIPTION
Install_name_tool changes the dynamic shared library install names and
or adds, changes or deletes the rpaths recorded in a Mach-O binary.
For this tool to work when the install names or rpaths are larger the
binary should be built with the ld(1) -headerpad_max_install_names
option.
-change old new
Changes the dependent shared library install name old to new in
the specified Mach-O binary. More than one of these options can
be specified. If the Mach-O binary does not contain the old
install name in a specified -change option the option is
ignored.
-id name
Changes the shared library identification name of a dynamic
shared library to name. If the Mach-O binary is not a dynamic
shared library and the -id option is specified it is ignored.
-rpath old new
Changes the rpath path name old to new in the specified Mach-O
binary. More than one of these options can be specified. If
the Mach-O binary does not contain the old rpath path name in a
specified -rpath it is an error.
-add_rpath new
Adds the rpath path name new in the specified Mach-O binary.
More than one of these options can be specified. If the Mach-O
binary already contains the new rpath path name specified in
-add_rpath it is an error.
-delete_rpath old
deletes the rpath path name old in the specified Mach-O binary.
More than one of these options can be specified. If the Mach-O
binary does not contains the old rpath path name specified in
-delete_rpath it is an error.
SEE ALSO
ld(1)