【问题标题】:Ubuntu 16.04: Cannot add path to LD_LIBRARY_PATHUbuntu 16.04:无法将路径添加到 LD_LIBRARY_PATH
【发布时间】:2018-03-16 19:30:35
【问题描述】:

我想在编译应用程序时使用额外的库,但我无法将库目录的路径添加到 LD_LIBRARY_PATH,因此构建系统找不到它:

我在包含/home/klaus/OpenFOAM/klaus-5.0/petsc-3.7.6/arch-linux2-c-debug/lib的新文件petsc.conf中添加了库目录/etc/ld.so.conf.d的路径

当我运行 ldconfig -p 时,找到了库,但它没有出现在 LD_LIBRARY_PATH

我还添加了.bashrc的路径

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/klaus/OpenFOAM/klaus-5.0/petsc-3.7.6/arch-linux2-c-debug/lib

找到它,后来重新启动,但是当我用

检查LD_LIBRARY_PATH

env | grep '^LD_LIBRARY_PATH'

该库仍未包括在内,我收到一个编译错误,即未找到(已链接)

除了这些步骤之外还需要做什么才能将库添加到LD_LIBRARY_PATH

【问题讨论】:

  • LD_LIBRARY_PATH 用于动态加载库。在编译你的.so的路径中尝试LD_LIBRARY_PATH=$PWD

标签: c++ ubuntu-16.04


【解决方案1】:

假设我在文件名temp.c 中使用libfunc.so


man 3 dlopen:

       dlclose, dlopen, dlmopen - open and close a shared object

SYNOPSIS
       #include <dlfcn.h>

       void *dlopen(const char *filename, int flags);

       int dlclose(void *handle);

       #define _GNU_SOURCE
       #include <dlfcn.h>

       void *dlmopen (Lmid_t lmid, const char *filename, int flags);

       Link with -ldl.

第一种使用动态库的方式(=直接告诉链接器):

ALP ❱ gcc temp.c -ldl
ALP ❱ ./a.out
libfunc.so: cannot open shared object file: No such file or directory
ALP ❱ pwd
/home/shu/codeblock/ALP
ALP ❱ gcc temp.c -ldl -Wl,-rpath,/home/shu/codeblock/ALP
ALP ❱ ./a.out
func1: 1
func2: upgrading to version 2

第二种使用动态库的方式(=使用环境变量LD_LIBRARY_PATH):

ALP ❱ export LD_LIBRARY_PATH=$PWD
ALP ❱ echo $LD_LIBRARY_PATH
/home/shu/codeblock/ALP
ALP ❱ ./a.out
func1: 1
func2: upgrading to version 2
ALP ❱ export LD_LIBRARY_PATH=
ALP ❱ ./a.out
libfunc.so: cannot open shared object file: No such file or directory

第三种使用动态库的方法(= 复制到标准路径):

ALP $ sudo cp libfunc.so /usr/lib
ALP ❱ gcc temp.c -ldl
ALP ❱ ./a.out
func1: 1
func2: upgrading to version 2

注意

如何在a.out 文件中找到路径
首先编译它并使用stringsgrep

ALP ❱ gcc temp.c -ldl -Wl,-rpath,/home/shu/codeblock/ALP
ALP ❱ strings a.out  | grep \/
/lib/ld-linux.so.2
/home/shu/codeblock/ALP

已在 Ubuntu 16.04 LTS 上测试

【讨论】:

  • 什么都没有被问到,sudo cp libfunc.so /usr/lib?嗯?不要碰你的系统目录。
  • 我不是在谈论权利,我在谈论明智的行为。你当然有权破坏你的系统。当然,您对不属于您的系统没有太多权利。
  • 既然你的分数比我高,就让你自己告诉我吧。最终,共享对象会转到标准路径,当然标准路径也适用于此,就像那里的其他文件一样。
  • 如果您构建 Linux 发行版,您可以决定 /usr/lib 中的内容。否则,不,你的库绝对不会去 /usr/lib。
  • First cp a lib for test 没有问题 never 因为它可以是 rm -f 以后。 第二我的回答是完美的,然后是其他的,我只是让用户/OP选择其中一个;最好是标记为重复的。不管怎样,谢谢你让我更了解你。
【解决方案2】:

LD_LIBRARY_PATH 不影响链接。 LD_LIBRARY_PATH 在加载时用于覆盖默认库搜索路径。您应该使用库的完整路径(如g++ -l/path/to/mylib/lib_mylib.so ...)或提供搜索路径(如g++ -L/path/to/mylib/

在运行时,使用LD_LIBRARY_PATH 或使用-rpath 选项链接(在链接时添加非默认库搜索路径)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-06-23
    • 1970-01-01
    • 1970-01-01
    • 2016-12-13
    • 1970-01-01
    • 2019-02-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多