未找到/ usr / local / lib中的库 [英] Libraries in /usr/local/lib not found

问题描述

我正在使用名为 ohNet 的框架构建应用程序。
构建框架后，可以通过 make install 安装框架。默认情况下，这些库安装在 / usr / local / [lib | include] 文件夹的内部。好吧，

我正在使用eclipse进行开发。为了使用这个库，我必须设置库的include路径（在这种情况下为 usr / local / include / ohnet ），设置链接器搜索路径）（ / usr / local / lib / ohnet ）和特定的库（-l）（在这种情况下，我选择一个名为 libohNet.so 其中是在这个文件夹
当我在eclipse中构建项目它可以正常工作，但是如果我尝试运行程序，我面临以下消息：

 加载共享库时出错：libohNet.so：无法打开共享对象文件：没有这样的文件或目录
  

我已经检查过这个，文件 libohNet.so 在这个目录下！
这个文件找不到的原因是什么？

我在google上搜索并发现一些帖子，说这是有问题的库正在安装到 / usr / local / lib 而不是 / usr / lib 看到这里 ...
我必须在 eclipse 中配置一些其他设置，使 ld 识别此路径中的库吗？这是什么解决方案？

认为

解决方案

这是一个运行时错误，而不是构建错误。设置 -L 标志对运行时链接程序不起作用。您需要做的是告诉运行时加载程序，也可以在/ usr / local / lib中查找库。你可以通过两种方法来实现。第一个是添加 LD_LIBRARY_PATH 环境变量的路径：

 
 export LD_LIBRARY_PATH =$ LD_LIBRARY_PATH：/ usr / local / lib
 

第二个是更新运行时链接程序的配置文件。这可以在/etc/ld.so.conf文件中，通过放置以下行：

 
 / usr / local / lib 
 

该文件的某处，或者在/etc/ld.so.conf.d/目录中创建一个新的* .conf文件，包含新路径。例如：

 
 /etc/ld.so.conf.d/99local.conf 
 

只需：

 
 / usr / local / lib 
 

。这是推荐的方法，因为它允许您将自定义库路径与系统设置的路径分开。 （99前缀是确保文件最后加载与其他文件相比，因此它不会抢占可能包含相同库的系统路径。）

/ p>在/ etc中修改/创建文件后，您需要运行：

 
 ldconfig 
 

作为root用于更改生效。 （此命令更新/etc/ld.so.cache文件，这是运行时链接程序使用的实际文件。）

还有另一种方法可以使二进制文件在运行时找到所需的库。实际上，您可以将库路径硬编码到可执行文件本身。这是通过设置一个所谓的rpath来实现的。这是一个链接器选项，必须从gcc（或g ++）传递给链接器，因此必须使用 -Wl 选项。链接器选项是 -rpath = PATH 。所以你需要添加到你的链接标志：

 
 -Wl，-rpath = / usr / local / lib 
 

我不建议你这样做。当您将库与可执行文件（可能与安装程序一起发送）和相对rpath（使用 rpath $ ORIGIN 功能）或绝对（例如，当您在/ opt中安装时），然后用于在运行时查找捆绑的lib。

I am building an application using a framework called ohNet. After building the framework, there is the possibility to install the framework via make install. By default the libraries are installed inside the /usr/local/[lib|include] folders. ok.

I am using eclipse for development. In order to use this libraries I have to set the include path to the library (in this case usr/local/include/ohNet), set the Linker search path (-L)(/usr/local/lib/ohNet) and specific libraries (-l) (in this case i choose a library called libohNet.so which is in this folder. When I build the project in eclipse it works fine, however if i try to run the programm i am faced with the following message:

error while loading shared libraries: libohNet.so: cannot open shared object file: No such file or directory

I've double checked this, and the file libohNet.so is in this directory! What's the reason that this file cannot be found?

I searched on google and found some posts, saying that it is problematic that libraries are getting installed into /usr/local/lib instead of /usr/lib see here ... Do I have to configure some additional settings in eclipse to make ld recognize libraries in this path? What's the solution for this?

regards

解决方案

This is a runtime error, not a build error. Setting the -L flag does nothing for the runtime linker. What you need to do is to tell the runtime loader to also look in /usr/local/lib for libraries. You can do that in two ways. The first is to add the path to the LD_LIBRARY_PATH environment variable:

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/lib"

The second is to update the configuration file of the runtime linker. This can happen either in the /etc/ld.so.conf file, by putting the line:

/usr/local/lib

somewhere in that file, or by creating a new *.conf file in the /etc/ld.so.conf.d/ directory that contains the new path. For example:

/etc/ld.so.conf.d/99local.conf

with just:

/usr/local/lib

in it. This is the recommended way of doing this, as it allows you to keep your custom library paths separate from paths set by the system. (The "99" prefix is there to make sure the file is loaded last compared to other files there, so that it won't preempt system paths that could contain the same libraries.)

After you modify/create the file in /etc, you need to run:

ldconfig

as root for the change to take effect. (This command updates the /etc/ld.so.cache file, which is the actual file used by the runtime linker.)

There's also another way for a binary to find needed libraries at runtime. You can actually hard-code library paths into the executable itself. This is accomplished by setting a so called "rpath". This is a linker option and must be passed from gcc (or g++) to the linker, so the -Wl option has to be used. The linker option is -rpath=PATH. So you would need to add this to your link flags:

-Wl,-rpath=/usr/local/lib

I don't recommend this for your case though. An rpath is useful when you're shipping libraries together with your executable (maybe with an installer), and a relative rpath (using the rpath $ORIGIN feature) or absolute one (for when you install in /opt, for example) is then used to find those bundled libs at runtime.

这篇关于未找到/ usr / local / lib中的库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！