错误：dlopen（）库未加载原因：图像未找到 [英] Error: dlopen() Library not loaded Reason: image not found

问题描述

我是这个领域的新手。我的笔记本电脑是Macbook Air，软件：OS X 10.8.5（12F45）。我正在运行一个代码，给我以下错误：

dlopen（/ Users / ramesh / offline / build_icerec / lib / icecube / phys_services .so，2）：库未加载：/Users/ramesh/offline/build_icerec/lib/libphys-services.dylib
引用来自：/Users/ramesh/offline/build_icerec/lib/icecube/phys_services.so
原因：图像未找到

我做过谷歌搜索，发现各种答案。我认为那个工作是使用

-install_name @ rpath / lib。

我的问题是，如何使用 -install_name @ rpath / lib 我的情况？

解决方案

OS X下的共享对象位置有时是棘手的。当您直接调用 dlopen（）时，您可以自由地指定库的绝对路径，这样可以正常工作。但是，如果您加载了另一个库（反过来需要加载另一个库）（因为您的情况），您就无法使用它的直接路径来指定库存在何处。

您可以在运行主程序之前设置的环境变量，告诉动态加载程序在哪里搜索内容。一般来说，这是一个坏主意（但是您可以通过OS X系统上的 man dyld 命令来阅读它们。）

OS X动态库被创建，它被赋予一个安装名称;该名称嵌入在二进制文件中，可以使用 otool 命令查看。 otool -L mach-o_binary 将列出您提供文件名的mach-o二进制的动态库引用;例如，这可以是主要的可执行文件或dylib。

当动态库静态链接到另一个可执行文件（主要可执行文件或另一个dylib）中时，预期的将被找到的dylib所在的位置是根据写入它的位置（在构建时或之后被应用的更改）的位置。在你的情况下，似乎 phys_services.so 与 libphys-services.dylib 静态链接。所以要开始，运行 otool -L phys_services.so 以找到dylib将在哪里的精确期望。

可以使用 install_name_tool 命令更改库的预期位置。它可以在dylib静态链接之前运行（在这种情况下，您没有任何事情可以做），或者可以针对加载它的可执行文件来运行它，以便重写这些期望。这个命令模式是 install_name_tool -change< old_path> < new_path> 例如，如果 otool -L phys_services.so 显示 / usr / lib / libphys- services.dylib ，并且您希望在您的问题中提出期望，您可以使用 install_name_tool -change /usr/lib/libphys-services.dylib @rpath /lib/libphys-services.dylib phys_services.so 。

dyld手册页（man dyld）会告诉你如何使用@rpath ，以及其他宏@loader_path和@executable_path。

I am a newbie in this field. My laptop is Macbook air, Software: OS X 10.8.5 (12F45). I am running a code which gives me the following error:

dlopen(/Users/ramesh/offline/build_icerec/lib/icecube/phys_services.so, 2): Library not loaded: /Users/ramesh/offline/build_icerec/lib/libphys-services.dylib Referenced from: /Users/ramesh/offline/build_icerec/lib/icecube/phys_services.so Reason: image not found

I did google search and found variety of answers. I think the one that works is to use

" -install_name @rpath/lib ".

My question is, how to use -install_name @rpath/lib in my case?

解决方案

Shared object location under OS X is sometimes tricky. When you directly call dlopen() you have the freedom of specifying an absolute path to the library, which works fine. However, if you load a library which in turn needs to load another (as appears to be your situation), you've lost control of specifying where the library lives with its direct path.

There are environment variables that you could set before running your main program that tell the dynamic loader where to search for things. In general these are a bad idea (but you can read about them via the man dyld command on an OS X system).

When an OS X dynamic library is created, it's given an install name; this name is embedded within the binary and can be viewed with the otool command. otool -L mach-o_binary will list the dynamic library references for the mach-o binary you provide the file name to; this can be a primary executable or a dylib, for example.

When a dynamic library is statically linked into another executable (either a primary executable or another dylib), the expected location of where that dylib being linked will be found is based on the location written into it (either at the time it was built, or changes that have been applied afterwards). In your case, it seems that phys_services.so was statically linked against libphys-services.dylib. So to start, run otool -L phys_services.so to find the exact expectation of where the dylib will be.

The install_name_tool command can be used to change the expected location of a library. It can be run against the dylib before it gets statically linked against (in which case you have nothing left to do), or it can be run against the executable that loads it in order to rewrite those expectations. The command pattern for this is install_name_tool -change <old_path> <new_path> So for example, if otool -L phys_services.so shows you /usr/lib/libphys-services.dylib and you want to move the expectation as you posed in your question, you would do that with install_name_tool -change /usr/lib/libphys-services.dylib @rpath/lib/libphys-services.dylib phys_services.so.

The dyld man page (man dyld) will tell you how @rpath is used, as well as other macros @loader_path and @executable_path.

这篇关于错误：dlopen（）库未加载原因：图像未找到的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！