替代 LD_PRELOAD 或 LD_LIBRARY_PATH

发布于 2024-10-28 11:47:26 字数 354 浏览 2 评论 0原文

我正在一台没有 root 访问权限的机器上进行一些 C 编程。我已经编译了一些要链接的共享库,但由于我无法将这些库安装在典型位置 (/usr/local/lib),所以我必须显式指定这些库的位置每次我编译并运行。编译时,这仅仅意味着将 -L 标志添加到 gcc 命令中,但对于程序执行来说,这就更烦人了。我必须将非标准目录添加到每个会话中的 LD_LIBRARY_PATH 中,或者必须将 LD_PRELOAD=/path/to/libs 添加到执行命令的开头。

有没有更好的方法在我没有 root 访问权限的计算机上执行此操作?

顺便说一句,该机器运行的是 Red Hat 4.1。

I'm doing some C programming on a machine for which I don't have root access. I've compiled some shared libraries that I'm linking to, but because I cannot install the libraries in the typical location (/usr/local/lib) I have to explicitly specify the location of the libraries each time I compile and run. When compiling, this simply means adding the -L flag to the gcc command, but for program execution it's a lot more annoying. Either I must add the non-standard directory to LD_LIBRARY_PATH in each session, or I must add LD_PRELOAD=/path/to/libs to the beginning of the execute command.

Is there a better way to do this on a machine for which I don't have root access?

BTW, the machine is running Red Hat 4.1.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

百变从容 2024-11-04 11:47:26

有几种解决方案,从好到坏:

  1. 使用 $ORIGIN,例如 gcc main.o -L../lib -lfoo -Wl,-rpath='$ORIGIN'/.. /lib
  2. 使用目标 RPATH,例如 gcc main.o -L../LIB -lfoo -Wl,-rpath=/home/user/lib
  3. 设置 LD_LIBRARY_PATH > 从您的 .bashrc.profile

解决方案 1 允许您在任何地方安装二进制文件,只要您将二进制文件和库移动在一起,例如 my-app/bin /a.out 和 my-app/lib/{needed-shared-libs}.so。它还允许应用程序的多个版本及其共享库集。

如果您只需要一组共享库,并且不想移动它们,则解决方案 2 可以正常工作。

解决方案 3 会影响您运行的每个应用程序,并可能导致其中一些应用程序绑定到您的共享库而不是系统库。这可能会导致它们崩溃、因未解析的符号而失败,或者给您带来其他痛​​苦。更糟糕的是,这个问题只会发生在你身上,不会发生在其他人身上,所以你很难获得帮助。

There are several solutions, from better to worse:

  1. Use $ORIGIN, e.g. gcc main.o -L../lib -lfoo -Wl,-rpath='$ORIGIN'/../lib
  2. Use target RPATH, e.g. gcc main.o -L../LIB -lfoo -Wl,-rpath=/home/user/lib
  3. Set LD_LIBRARY_PATH from your .bashrc or .profile

Solution 1 allows you to install the binary anywhere, so long as you move the binary and the libraries together, e.g. my-app/bin/a.out and my-app/lib/{needed-shared-libs}.so. It also allows for multiple versions of the application and their set of shared libs.

Solution 2 works fine if you only need one set of shared libs, and never wish to move them around.

Solution 3 affects every application you run, and may cause some of them to bind to your shared libraries instead of the system ones. That may cause them to crash, fail with unresolved symbols, or cause you other pain. To exacerbate, the problem will only happen to you and nobody else, so you'll have hard time getting help for it.

默嘫て 2024-11-04 11:47:26

您可以将环境变量添加到 .bashrc (或登录时 shell 源的任何文件)。

You can add the environment variables to your .bashrc (or whatever file your shell sources when you log-in).

旧城烟雨 2024-11-04 11:47:26

如果您在编译和链接程序时设置环境变量LD_RUN_PATH,那么该搜索路径将被烘焙到可执行文件中,并且动态链接器将在运行时搜索它。

If you set the environment variable LD_RUN_PATH when you compile and link your program, then that search path will be baked in to the executable, and the dynamic linker will search it at runtime.

疑心病 2024-11-04 11:47:26

使用 LD_LIBRARY_PATH 或 LD_PRELOAD 几乎就是实现此目的的方法。要解决此问题,请将程序从 myprog 重命名为 myprog-exe,并创建一个名为 myprog 的 shell 脚本:

#!/bin/sh
export LD_LIBRARY_PATH=/path/to/libs:$LD_LIBRARY_PATH
`dirname $0`/myprog-exe

这样,当有人运行 myprog 时,它将真正运行 shell 脚本,然后再运行 myprog。

Using LD_LIBRARY_PATH or LD_PRELOAD is pretty much how to do this. To fix this, rename your program from myprog to myprog-exe, and create a shell script that looks like this called myprog:

#!/bin/sh
export LD_LIBRARY_PATH=/path/to/libs:$LD_LIBRARY_PATH
`dirname $0`/myprog-exe

This way, when someone runs myprog, it will really run the shell script which then runs myprog.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文