Ensembles/ert — pull request #377 by blattms (2014-02-10 15:00:18+00:00)
Title: [cmake] Fix rpath issues with shared libraries in non-system installation paths

When installing ERT into non-system installation prefixes, binaries will not
be linked correctly as the rpath is wrong. On my system this looks like this
(notice the not found!):

ldd /home/mblatt/src/dune/3rdParty/ert/lib/x86_64-linux-gnu/libecl.so.1.0
linux-vdso.so.1 => (0x00007fff7fbff000)
libert_geometry.so.1.0 => not found
libert_util.so.1.0 => not found
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f45dd80d000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f45dd5f6000)
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f45dca25000)
libopenblas.so.0 => /usr/lib/libopenblas.so.0 (0x00007f45db57a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f45db2f8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45db0f4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45dad69000)
/lib64/ld-linux-x86-64.so.2 (0x00007f45ddca1000)
libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f45daa53000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f45da83d000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f45da607000)

The same holds for binaries where ert is linked to.

This can circumvented by setting LD_LIBRARY_PATH, but this seems rather cumbersome. Instead in this patch we follow the approach suggested in http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH