14

I am installing a program on a server as a non-root user. Specifically it is tmux 1.5, but this should apply broadly to all locally installed program in my opinion (I mention the program name in case this problem ends up not being my own error).

The program requires me to install some dependent libraries (e.g. libevent and ncurses). So, I installed them both locally since I do not have root access

cd $HOME/library/installation/folder
DIR=$HOME/local
./configure --prefix=$DIR 
#... make ... make install 

Now, to install the program, I also had to include the library packages:

cd $HOME/program/installation/folder
./configure --prefix=$DIR CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib"
#... make ... make install 

Ok, so this installs the program without problems into $HOME/local/bin, but if I run the executable: $HOME/local/bin/tmux , I get the following error:

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

It would seem to me that the program cannot find the desired libraries, but the file libevent-2.0.so.5 does indeed exist in $HOME/local/lib as specified in the configure options. I am wondering how I can get the program to recognize the installed library in order to run. I tried putting symbolic links in $HOME/lib, $HOME/bin, and $HOME/local/bin, but none of these worked. Any ideas and suggested would be greatly appreciated

1
  • I assume -R $DIR/lib to CFLAGS is while building tmux (and not libevent). This did not help me – there was some final error from gcc saying it can't recognize -R (also, I tried without the space between -R and $DIR). ./configure --disable-shared This worked, updating the LD_LIBRARY_PATH also worked. I ended up making libevent again with the above --disable-shared option.
    – user108497
    Commented Dec 7, 2011 at 5:53

4 Answers 4

22

Try re-building libevent using

./configure --disable-shared

I suspect this will fix your problem because the library will be linked against when building the binary and doesn't need to be searched for at runtime.

Alternatively, if you have a need for a dynamically linked libevent, you can add the containing directory of libevent-2.0.so.5 to your LD_LIBRARY_PATH environment variable:

export LD_LIBRARY_PATH=${HOME}/local/lib/:${LD_LIBRARY_PATH}
1
  • Wow, thanks a lot for the quick reply. I ended up using LD_LIBRARY_PATH to fix the problem since I could simply apply this fix to any future library installations and always use the $HOME/local directory. Appreciate the help! Commented Aug 18, 2011 at 1:45
7

You could also set the RPATH, which encodes the library search patch in the binary itself.

Just add -R $DIR/lib to CFLAGS.

0
3

I have asked a similar question, interestingly enough also about building tmux of all things, although I am still certain this shouldn't pertain to just about any situation where GNU configure and make are used together.

I believe a cleaner approach is to utilize the so-called "rpath" - the library search path embedded in the binary. The -rpath switch of at least GNU linker ld allows one to specify the "rpath".

The build command line then would look as follows:

PKG_CONFIG_PATH=/path/to/libevent/lib/pkg-config LDFLAGS=-Wl,-rpath,/path/to/libevent/lib ./configure ...

Not really paramount here, but PKG_CONFIG_PATH above is simply the recommended way to do what people otherwise achieve manually sending -L/path/to/libevent/lib -I/path/to/libevent/include to ./configure script. When you build libevent, it installs its own configuration files for pkg-config (which is used by ./configure). You should use it, because only libevent definitely knows what switches should be used when building against it.

Anyway, in some situations, -rpath is a cleaner approach to solving the problem.

LD_LIBRARY_PATH-based solutions, however, allow you to juggle the library used by your built binary at runtime, which is sometimes desirable. But if you just want to build against a particular library you have put in a dedicated place in your home folder somewhere, I think -rpath-based solutions are to regard as a canonical answer.

The strange thing is why tmux' own build scripts do not infer this path from library search path during building. Maybe they need not and should not, I do not know. Is it a coincidence this has happened to us who build tmux?

2

No luck with the others, but this worked for me, from here:

sudo ln -s /usr/local/lib/libevent-2.0.so.5 /usr/lib64/libevent-2.0.so.5

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .