【问题标题】:How to force using local shared libraries over system libraries?如何强制使用本地共享库而不是系统库?
【发布时间】:2012-11-02 06:03:55
【问题描述】:

如何在 linux 中强制使用本地库而不是系统库?

我将我的可执行文件显式链接到我的项目/lib 目录中的一些 .so 文件,例如(../lib/libluajit.so)。

在 gdb 下运行我的可执行文件或使用 ldd 表明它仍然使用系统 libluajit-5.1.so.2

然后我将 LD_LIBRARY_PATH 设置为我的项目/lib 目录并将其导出,然后运行我的可执行文件。不知何故,它仍在获取系统库(由 gdb 和 ldd 确认)

我想知道这怎么可能,以及我可以做些什么来强制它使用我的项目/lib 目录中的本地 libluajit.so。

【问题讨论】:

    标签: c++ c linux linker shared-libraries


    【解决方案1】:

    我不得不质疑为什么您要使用您自己的库版本而不是系统提供的版本(有多个不同的版本四处浮动只会造成麻烦和用户混淆)。

    但是,您应该能够export LD_PRELOAD=<path_to_your_shared_obj> 强制它加载您自己的版本。

    请注意,任何类型的权限提升(例如sudo)都不会保留覆盖库版本的机制。

    【讨论】:

    • 简短的回答是这个构建只适用于我,用户构建使用静态库。
    • 您想要这样做的原因可能有很多,例如,在不干扰使用生产软件的共享系统上的其他用户的情况下构建一个实验性软件
    • “我不得不质疑你为什么要使用自己的库版本而不是系统提供的版本......” - 可能类似于make gdb load a shared library from a specific path
    【解决方案2】:

    链接时,指定库的目录并使用rpath:

    -Wl,-rpath,/absolute/path/to/your/library -L/absolute/path/to/your/library -llibrary

    -L 告诉链接器在链接时在哪里找到你的库,-rpath 告诉它在运行时在哪里搜索库。

    请注意,-L-rpath 需要包含 .so 文件的目录,而不是库文件本身的实际路径。

    【讨论】:

    • 这对我不起作用,不知何故它仍然在寻找 libluajit-5.1.so.2 而我似乎没有做任何事情(比如删除系统库和重建 ld 缓存)似乎很重要.我完成的最好的事情是它无法在运行时加载 libluajit-5.1.so.2。它可能从哪里得到这个特定的名字?我的系统中不再存在同名的文件。
    • @Eloff 你做错了什么。或者,程序正在尝试使用 dlopen 打开库?我们至少可以看到您的链接步骤的完整命令行吗?
    • 我很确定 rpath 仅 附加到 rpath:当库存在于标准位置时,仍将使用该库。
    • @MarkB 不在这里。例如,我可以cp -a /usr/lib/libpng* /tmp,并将 rpath 设置为 /tmp。然后 ldd 显示可执行文件加载 /tmp/libpng15.so.15。
    • 我 grepped libluajit.so 并在其中找到了名称 libluajit-5.1.so.2。因此,凭直觉,我将该名称添加到 libluajit.so 的符号链接,并将该名称的系统库移回系统 lib 目录。现在使用您的技术加载正确的库。谢谢!
    猜你喜欢
    • 2023-04-04
    • 1970-01-01
    • 2011-05-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多