…ibcmark.so'
Before this commit, the 'cmark' executable didn't inform the
dynamic linker where to look for the 'libcmark' shared object;
this becomes an irritation when libcmark is installed in an
unorthodox location:
$ ldd /path/to/installed/files/bin/cmark
linux-gate.so.1 (0xb7ed7000)
libcmark.so.0.31.0 => not found
libc.so.6 => /usr/lib/libc.so.6 (0xb7cf3000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xb7ed8000)
Because of this commit, the cmark executable's 'rpath' setting
(or equivalent) is set upon installation, thereby providing the
required search directory:
$ ldd /path/to/installed/files/bin/cmark
linux-gate.so.1 (0xb7ef2000)
libcmark.so.0.31.0 => /path/to/installed/files/lib/libcmark.so.0.31.0 (0xb7e95000)
libc.so.6 => /usr/lib/libc.so.6 (0xb7cbc000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xb7ef3000)
There is some intelligence behind whether rpath is set at all:
* If 'CMAKE_INSTALL_RPATH' is set, then it is used; this
allows the user to set a single, overriding value in
the expected way.
* Otherwise, the base case rpath is determined by the following:
"${CMAKE_INSTALL_FULL_LIBDIR}"
If that path is a standard location, then the base case rpath
is the empty string; otherwise, the base case rpath is that
path.
* The cmark executable's rpath is set to the base case rpath.
* Currently, libcmark's rpath is set to the empty string.
* In addition, cmake has been instructed to add to each target's
rpath any directories that it thinks might contain potential
dependencies from outside the project; most of the time, there
will be none, and so nothing will be added.
Of course, this will only help on a system that supports an rpath
feature known to cmake; for example, Windows has no such feature,
and so all of this will presumably be ignored when building under
that system.