我正在一个非常普通的 Linux 主机上从源代码构建 tmux-2.0。第一次尝试失败，因为安装的 libevent 版本比要求的版本旧，所以我首先从源(撰写本文时的当前版本)下载并构建 libevent-2.0.22。
libevent 的构建完美地成功，然后我想我可以使用以下命令重试构建 tmux：
1
|
PKG_CONFIG_PATH=$PATH_TO_MY_BUILT_LIBEVENT/lib/pkgconfig ./configure ...
|
上述调用成功，随后的make 和make install 也成功。
运行我新构建的 tmux，但是，由于缺少共享对象而中止，这并不奇怪 libevent-2.0.so.5:
1
|
tmux: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory
|
我认为针对自定义库构建意味着它也将在运行时使用？我的 tmux 上的 ldd 给了我：
1
2
3
4
5
6
7
8
9
10
11
|
linux-vdso.so.1 => (0x00007fff8f5ff000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003cf8800000)
libncurses.so.5 => /lib64/libncurses.so.5 (0x0000003cf7e00000)
libevent-2.0.so.5 => not found
librt.so.1 => /lib64/librt.so.1 (0x0000003ce8600000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003cea200000)
libc.so.6 => /lib64/libc.so.6 (0x0000003ce7600000)
libtinfo.so.5 => /lib64/libtinfo.so.5 (0x0000003cf7200000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003ce7e00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ce8200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003ce7200000)
|
所以，libevent-2.0.so.5 没有找到。
我是否需要求助于设置，我不知道，LIBS、LDFLAGS 或其他一些变量或切换到上面的 configure 脚本，所以我不知道路径我新建的 libevent 嵌入在 tmux 二进制文件中，由 ld?
提供
我没有 root 访问权限 - 大学 Linux 工作站 - 坦率地说，我认为我不需要。我也不想弄脏 LD_LIBRARY_PATH 之类的东西。可以说，做 LD_LIBRARY_PATH=$PATH_TO_MY_LIBEVENT/lib tmux 工作正常。但我希望它"默认"工作，定位并使用我的 libevent。
我猜这个解决方案几乎适用于任何使用"GNU 构建系统"的软件。在这里做什么是正确的？
- 我不知道 "tmux" 或你的 Linux 环境的细节。但总的来说，你会 1) make clean：删除你当前的二进制文件； 2) ./configure：让 GNU 构建为您的环境重新配置您的构建设置。据推测，这应该检测到 libevent-2.0.22。最后，3) make && make install：从头开始重建。
嗨 paulsm4，您为什么确信 ./configure(我假设没有开关？)应该检测到 libevent-2.0.22？我不希望它 - 我可以在任何地方构建库，它不像脚本从 / 或任何东西开始对其进行递归查找。但是，如果我告诉它使用位于 PKG_CONFIG_PATH 变量指示的路径的 pkg-config 文件，它确实应该使用它，这就是我所做的。一切都很好，只是构建的二进制文件无法找到它应该是 ./configured 的库！
您针对库构建，但系统不知道库在哪里。由于您不想安装库，而是将其留在构建它的位置，因此您可以使用链接器的 -rpath= 选项解决它，因为它将库的搜索路径嵌入到可执行文件中。
只需重建您的应用程序，并将其添加到您的 LDFLAGS 中，例如 LDFLAGS="-rpath=/home/mypath/to/libevent"(但请注意，它是一个链接器选项，并且可能在 makefile 中作为链接器使用 gcc 本身a€" gcc 不知道该选项，那么您需要像 LDFLAGS="-Wl,-rpath=/home/mypath/to/libevent" 一样编写它以强制 gcc 将选项向下传递给实际的链接器)
顺便说一句，实际上你甚至可以在不重新编译应用程序的情况下更改 rpath，因为有一个工具 patchelf 可以完成这项工作。
- "rpath" 是 B 计划。"configure" 应该自动检测库的可能性相当大。否则，"configure" 可能有一个命令行选项来强制链接器选项(包括 rpath)。手动编辑生成文件应该是"最后的手段"。
@paulsm4 从你的评论中我猜你已经漫不经心地阅读了这个问题。作者已经构建了一个库，然后针对该库构建了一个应用程序。在他们运行可执行文件后，他们显然收到了关于缺少库的错误。他们没有安装构建库的 root 访问权限，并且他们不想处理 LD_LIBRARY_PATH 变量，因此更改 rpath 是唯一剩下的选择。
非常有用，谢谢你，Hi-Angel。我不认为 tmux 细节会影响这一点，它可能在构建任何 ./configure && make && make install 或 autoconf 风格的软件时发生。而且我认为我无需接触任何 makefile 就可以逃脱，这可能是 paulsm4 正确建议的仅仅是"计划 B" - ./configure --help 告诉我我可以提供各种环境变量，包括 LIBS 和 LDFLAGS，我认为其中之一与您的建议相结合应该具有我正在寻找的效果。
@amn 您不需要触摸 makefile，如果您查看 tmux 目录中的 INSTALL 或 README 文件(不确定是哪一个)，您会看到，您可以在配置构建时提供自定义 LDFLAGS 而无需编辑任何文件。此外，正如我所提到的，您可以使用 patchelf 编辑可执行文件。
谢谢，我会按照你的建议去做。顺便说一句，您对为什么仅提供 \'PKG_CONFIG_PATH\' 不够有意见吗？如果没有 PKG_CONFIG_PATH 构建会失败，而将其放置到位会导致我的 libevent 被正确定位和使用，但是为什么库链接不会一直传播到构建的二进制文件中呢？
@amn 我应该说不幸的是我从未使用过 pkg-config。但是从很少的搜索中，我发现该应用程序只是为构建时间提供了一些环境变量；它似乎没有修改 rpath，因此显然运行时链接器仍然对用于编译时的 lib 一无所知。顺便说一句，我应该提到，要为库提供自定义路径，您宁愿在 LDFLAGS 中使用 -L 选项而不是 PKG_CONFIG_PATH。
好吧，pkg-config 也会生成 -L... 标志字符串，所以它就像您直接在 LDFLAGS 中提供了 -L 一样，无论如何。
最后像魅力一样工作。谢谢！
京公网安备 11010802041100号