building code from source and adding them to your path

Question

Typically on Debian when you install things from the repository, they just work. It sets up things just fine and life is good. This is great for things that are up to date in the repository.

I am building some tools that I would like to manually update from github or mercurial.

using cmake or the configure script to build the code is fine, I also add my own prefix path so that I can easily remove or update the packages if need be.

I just build SDL2 from mercurial and installed it into /opt/SDL2 and added that to my path. I had to do that to be able to build SDL_image

which gave me this output after finishing it's process.

Libraries have been installed in:
   /opt/SDL_IMAGE/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.

This output above says a lot and I am not really sure how to parse it. In the past I used a mac which simplified a lot of this stuff but on linux I am having some trouble.

My understanding from reading that above code is that I should add something like this to my bashrc file.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/SDL_IMAGE/lib
export LD_RUN_PATH=$LD_RUN_PATH:/opt/SDL_IMAGE/lib

to my bashrc, so that when I am linking against sdl image headers it'll find it? I've skimmed the man pages for ld but honestly I don't get it and that's why I am asking.

Especially this line: use the `-Wl,-rpath -Wl,LIBDIR' linker flag

Answer 1

Xcode and Fink|Homebrew|MacPorts on Mac OS X have these complications (they just largely hide it from you). There are two aspects to this problem, compiling, and running. Compiling will require a variety of details for any library installed to a custom path. This info for some libraries can be provided by pkg-config, e.g. for a little software depot I maintain under my home directory:

$ ls ~/usr/rhel6-x86_64/lib/pkgconfig/
goptfoo.pc  jkiss.pc  libsodium.pc
$ echo $PKG_CONFIG_PATH
/homes/jdoe/usr/rhel6-x86_64/lib/pkgconfig
$ pkg-config --libs --cflags libsodium
-I/homes/jdoe/usr/rhel6-x86_64/include  -L/homes/jdoe/usr/rhel6-x86_64/lib -lsodium  
$ 

These magic strings must be fed into the compile process for any software that is being built against libraries in your custom install tree. Details will vary depending on whether Makefile or autotools or cmake or so forth. One easy way is to set CFLAGS to contain the pkg-config output, or just include the output on the build line:

mkpwhash: mkpwhash.c
        gcc -std=gnu99 `pkg-config --cflags --libs libsodium` -lcrypt -Werror -Wall -Wextra -Wundef -ftrapv -fstack-protector-all -pedantic -pipe -o mkpwhash mkpwhash.c

For autotools or cmake, you'll need to dig around to see how they attach this particular onion to their belt, e.g. study existing configure.ac configurations from packages that use autotools, etc.

For running something that has been compiled to use a shared library from the custom path, setting LD_LIBRARY_PATH probably will suffice (or, system-wide, fiddle with ld.so.conf):

$ unset LD_LIBRARY_PATH
$ ldd ~/usr/rhel6-x86_64/bin/mkpwhash | grep sodium
        libsodium.so.13 => not found
$ exec $SHELL
$ echo $LD_LIBRARY_PATH 
/homes/jdoe/usr/rhel6-x86_64/lib
$ ldd ~/usr/rhel6-x86_64/bin/mkpwhash | grep sodium
        libsodium.so.13 => /homes/jdoe/usr/rhel6-x86_64/lib/libsodium.so.13 (0x00007e5c12ca7000)
$

(This being unix, there are several ways to exfoliate the Bos grunniens, hence the "at least one of..." advice from your build process output. More complicated software depots will likely use stow or similar, depending on how much rope (and, thus, headaches) you want to give yourself.)