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

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-09 04:19:23  来源:igfitidea点击:

How to properly set run paths, search paths, and install names?

xcodemacosxcode4.2dylibdyld

提问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 -Lon 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 -changeon the various libraries, I am able to successfully change the run path search paths (again as verified by running otool -Lto 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_PATHaka "Installation Directory" to the prefix I want (e.g. @executable_path/../Frameworks).

通常,在我的 dylib 目标中,我将INSTALL_PATH又名“安装目录”设置为我想要的前缀(例如@executable_path/../Frameworks)。

I leave LD_DYLIB_INSTALL_NAMEaka "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 otoolis 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 -Lon the built dylib. The first line for each architecture should be what LD_DYLIB_INSTALL_NAMEwas 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_toolis 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_toolwithout the need for a separate build.

install_name_tool对于设置名称和路径非常有用。如果程序在构建目录中运行自检,然后在make install. 在这种情况下,您install_name_tool无需单独构建即可使用。

install_name_toolis also useful because Apple's LD does not honor rpathlinker 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)