【问题标题】:What path does @loader_path resolve to?@loader_path 解析到什么路径?
【发布时间】:2013-05-25 11:35:10
【问题描述】:

我很难理解文件中 @loader_path 所指的绝对路径。

user@local:~$ otool -L zlib.so 
zlib.so:
    @loader_path/../../libz.1.dylib (compatibility version 1.0.0, current version 1.2.7)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)

我想知道系统在哪里寻找 libz.1.dylib。

来自Mac documentation:

@loader_path/ 此变量被替换为包含 mach-o 二进制文件的目录的路径,其中包含使用 @loader_path 的加载命令。因此,在每个二进制文件中,@loader_path 都会解析为不同的路径

我猜这意味着@loader_path 只是目标文件 (zlib.so) 的路径,但这似乎不是真的。

是否有任何命令行实用程序可以将@loader_path 解析为尝试打开库时使用的实际路径?

【问题讨论】:

    标签: macos shared-libraries mach-o dyld otool


    【解决方案1】:

    您的猜测是正确的:在这种情况下,@loader_path 是目录的路径,包含 zlib.so。但是使用这个库可能会有问题。你从哪里得到那个库?如果您自己构建它,请参阅this question 了解一些信息。
    @loader_path 对框架和插件很有用,但对独立库没有用。

    【讨论】:

    • 感谢您对@loader_path 的确认。最终,我想要给定目标文件所依赖的库的完整列表,以及系统将在哪里寻找它们。有没有一种简单的方法来生成该列表?
    • 嗯,目标文件不依赖于任何库。链接器设置依赖关系,因此只有目标二进制文件具有依赖关系。 otool -L <binary> 是查看它们的方式。所有可以帮助解决这些路径的其他信息都在man dyld(即您提供的链接)中
    • 请问为什么这对独立库没有用处?我正在尝试将一个库编译为可移植的。我应该使用其他东西吗?我是通过从blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_mac 查找@loader_path 的含义而来到这里的
    • 据我所知,因为@loader_path 是关于相对的东西。在插件中,您只有很少的二进制文件,它们可以相互关联,如果您使用@loader_path 链接它们,您可以安全地在文件系统中移动插件本身。但是在独立库的情况下,为什么需要该路径?查看man dyld 中有关@loader_path 的部分以获取信息
    • @cody 感谢与问题相关的更高级别的答案,以及 man dyld 记录它的提示!
    猜你喜欢
    • 1970-01-01
    • 2018-03-30
    • 1970-01-01
    • 2021-07-15
    • 1970-01-01
    • 2012-11-28
    • 2017-03-03
    • 1970-01-01
    • 2014-07-31
    相关资源
    最近更新 更多