[lldb-dev] Heads-up: FreeBSD LLDB CMake build broken by relative rpath change

Brad King brad.king at kitware.com
Thu Feb 27 05:46:10 PST 2014

On 02/27/2014 07:49 AM, Rafael EspĂ­ndola wrote:
> On 26 February 2014 21:40, Ed Maste <emaste at freebsd.org> wrote:
>> This at least has a straightforward explanation -- for the configure
>> build my binary ends up with an rpath containing both the
>> $ORIGIN-based relative path as well as an absolute path:
>> feynman% readelf -d ./Debug+Asserts/bin/lldb | grep PATH
>>  0x000000000000000f (RPATH)              Library rpath:
>> [$ORIGIN/../lib:/tank/emaste/src/llvm/build-make/Debug+Asserts/lib]
>>  0x000000000000001d (RUNPATH)            Library runpath:
>> [$ORIGIN/../lib:/tank/emaste/src/llvm/build-make/Debug+Asserts/lib]
> Brad, is there a way to add to rpath from an inner CMakeLists.txt?

The CMAKE_INSTALL_RPATH variable is not actually a global setting
but is rather used to initialize the INSTALL_RPATH target property:


on each library or executable target as it is created.  One may
append to an individual target's INSTALL_RPATH property or may
set CMAKE_INSTALL_RPATH in the current directory scope to influence
targets in the directory and below.

IIUC the reason LLVM can use BUILD_WITH_INSTALL_RPATH is because
it is careful to lay out the build tree binaries the same way as
they appear in the install tree so $ORIGIN/../lib works in both
places.  If LLDB is building externally then its binaries will not
appear in the right relative location to use that RPATH.  It could


so that LLDB binaries are built and installed with the RPATH pointing
at locations used at link time to search for external libraries.

Alternatively it could not use BUILD_WITH_INSTALL_RPATH and instead
allow CMake to handle the build-tree RPATH as it likely did before
this change.


More information about the lldb-dev mailing list