3

I am building tmux-2.0 from sources on a pretty regular Linux host. First attempt failed as it turned out that the version of libevent installed is older than required, so I proceeded to download and build libevent-2.0.22 from sources (current at the time of writing) first.

Building of libevent succeeded flawlessly, and I thought I could then retry building tmux with the following:

PKG_CONFIG_PATH=$PATH_TO_MY_BUILT_LIBEVENT/lib/pkgconfig ./configure ...

The above invocation succeeded, so did subsequent make and make install.

Running my newly build tmux, however, aborts with a missing shared object, not surprisingly libevent-2.0.so.5:

tmux: error while loading shared libraries: libevent-2.0.so.5: cannot open shared object file: No such file or directory

I thought building against a custom library implies it will also be used at runtime? ldd on my tmux gives me:

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)

So, libevent-2.0.so.5 is not found.

Do I need to resort to setting, I don't know, LIBS, LDFLAGS or some other variables or switches to configure script above, so that, I don't know, the paths to my newly built libevent are embedded in tmux binary, courtesy of ld?

I do not have root access - university Linux workstation - and frankly I don't need one, I think. I also do not want to muck about with LD_LIBRARY_PATH or the like. Suffice to say, doing LD_LIBRARY_PATH=$PATH_TO_MY_LIBEVENT/lib tmux works fine. But I want it to work "by default", locating and using my libevent.

I guess the solution would apply to pretty much any software using the "GNU build system". What's the right thing to do here?

Armen Michaeli
  • 8,625
  • 8
  • 58
  • 95
  • I don't know the specifics for either "tmux" or your Linux environment. But in general, you'd 1) `make clean`: delete your current binaries; 2) `./configure`: have GNU build reconfigure your build settings for your environment. Presumably, this should detect `libevent-2.0.22`. Finally, 3) `make && make install`: Rebuild from scratch. – paulsm4 Jun 20 '15 at 22:32
  • Hi paulsm4, why are you confident that `./configure` (without switches I assume?) should detect `libevent-2.0.22`? I don't expect it to - I could have built the library anywhere, it's not like the script does a recursive find for it starting from `/` or anything. But it *should* indeed use it *if* I tell it to use the `pkg-config` files residing at the path indicated by `PKG_CONFIG_PATH` variable, which is what I did. Everything builds fine, it's just that the built binary cannot locate the library it was supposedly `./configure`d with! – Armen Michaeli Jun 21 '15 at 10:33

1 Answers1

4

You built against a library, but the system doesn't know where the library is. Since you don't want to install the library, but rather leave it in the place where you built it, you could solve it with -rpath= option of the linker — it embeds a search path for libraries into the executable file.

Just rebuild your application with it being added to your LDFLAGS, like LDFLAGS="-rpath=/home/mypath/to/libevent" (but note, it is a linker option, and it is possible that in the makefile as a linker used the gcc itself — gcc does not know the option, then you need to write it likeLDFLAGS="-Wl,-rpath=/home/mypath/to/libevent" to force gcc to pass the option down to the actual linker)

By the way, actually you can change rpath even without recompiling the application — there's a tool patchelf for that job.

Community
  • 1
  • 1
Hi-Angel
  • 4,933
  • 8
  • 63
  • 86
  • 1
    "rpath" is Plan B. The odds are fairly good that "configure" should detect the library automatically. Otherwise, "configure" might have a command-line option to force linker options (including rpath). Manually editing the makefile(s) sould be a "last resort". – paulsm4 Jun 20 '15 at 23:47
  • 1
    @paulsm4 from both your comments I guess you have read the question inattentively. The author have built a library, and next an app against that library. And after they run the executable, they obviously got an error about the missing library. They have no root access to install the built library, and they don't want to tackle with `LD_LIBRARY_PATH` variable, so changing *rpath* is the only option that remains. – Hi-Angel Jun 20 '15 at 23:53
  • Very useful, thank you, Hi-Angel. I don't think `tmux` specifics figure into this, it could have happened while building any `./configure && make && make install` or `autoconf` -style software. And I think I can get away **without** having to touch any makefiles, which is what paulsm4 perhaps rightfully suggests as mere "plan B" - `./configure --help` tells me I can supply all kinds of environment variables, including `LIBS` and `LDFLAGS`, I think one of these combined with your advice should have the effect I am looking for. – Armen Michaeli Jun 21 '15 at 11:33
  • 1
    @amn you don't need to touch makefile, if you look at the *INSTALL* or *README* file *(not sure which one)* in the tmux directory, you will see, that you can provide custom LDFLAGS while configuring the build without having to edit any file. Besides, as I mentioned, you can just edit the executable file with *patchelf*. – Hi-Angel Jun 21 '15 at 11:54
  • Thank you, I will do exactly what you suggest. By the way, do you have an opinion on why simply providing 'PKG_CONFIG_PATH' does not suffice? Without `PKG_CONFIG_PATH` the build fails, while having it in place causes my `libevent` to be properly located and used, but then why would the library link not propagate all the way into the built binary? – Armen Michaeli Jun 21 '15 at 11:57
  • 1
    @amn I should say that unfortunately I've never worked with pkg-config. But from little searching I see that the app just provides some environment variable for build time; it doesn't seem to modify *rpath*, so obviously run-time linker still knows nothing about the lib being used for compile time. As aside note I should mention that to provide a custom path to a library you'd rather use `-L` option in LDFLAGS instead of PKG_CONFIG_PATH. – Hi-Angel Jun 21 '15 at 12:10
  • 1
    Well, `pkg-config` generates the `-L...` flag string as well, so it's exactly as if you had provided `-L` in `LDFLAGS` directly, anyway. – Armen Michaeli Jun 21 '15 at 12:32
  • Worked out like a charm in the end. Thank you! – Armen Michaeli Jun 21 '15 at 13:42