一尘不染

链接时LD_LIBRARY_PATH和-L有什么区别?

linux

LD_LIBRARY_PATH链接 时遇到问题(此问题与运行时无关)。

运行make时,链接线如下所示(这是使用g ++版本4.1.x的Linux系统):

g++ a.o b.o c.o -o myapp \
 -L/long/path/to/libs/ \
 -L/another/long/path/ \
 -labc -ldef -lghi

这些-l选项引用共享库(例如libabc.so),这些共享库位于-L选项指定的目录中。这些目录也出现在中LD_LIBRARY_PATH。使用该配置,链接成功,并且我可以运行该应用程序。

如果我从中删除目录LD_LIBRARY_PATH,则会得到一条错误行,例如:

/usr/bin/ld: cannot find -labc

另一方面,如果从-L选项列表中删除目录,则会收到许多警告,例如:

/usr/bin/ld: warning: libabc.so, needed by /long/path/to/libs/libxyz.so,
    not found (try using -rpath or -rpath-link)

然后出现更多错误,例如:

/long/path/to/libs/libdef.so: undefined reference to `Foo::Bar<Baz>::junk(Fred*)'

有人可以解释之间的差异LD_LIBRARY_PATH-L?我想深入了解这些内容,因此非常感谢参考!

另外,为避免使用链接,我还必须添加些LD_LIBRARY_PATH什么?

编辑: 目录缺少时-L,编译器建议“尝试使用-rpath或-rpath-link”。我认为我以前从未在Makefile中看到过这些选项。有吗
不确定是否可以LD_LIBRARY_PATH解决问题。


阅读 551

收藏
2020-06-03

共1个答案

一尘不染

的设置LD_LIBRARY_PATH具有最高优先级,因此在设置时,LD_LIBRARY_PATH甚至会在标准
目录集之前搜索提到的目录集。因此,在您的情况下,的设置LD_LIBRARY_PATH会影响
使用-loption 提及的库的查找。没有LD_LIBRARY_PATH一些依赖关系,
可能已经从标准目录集中解决了。

尽管设置LD_LIBRARY_PATH了调试帮助并尝试了
库的较新版本,但在常规开发环境的设置和部署中使用它被认为是不好的。

另请参阅Linux文档中的本HOWTO,以获取有关共享库的更多详细信息。

2020-06-03