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

[Ed Maste]

On 26 February 2014 15:12, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> On 26 February 2014 14:45, Ed Maste <emaste at freebsd.org> wrote:
>> LLVM r201936 restores the use of a relative rpath but this breaks LLDB
>> on FreeBSD.  For now I've disabled CMAKE_BUILD_WITH_INSTALL_RPATH
>> locally until the fix can be found, in the top-level LLVM
>> CMakeLists.txt:
>>
>> if(NOT ${CMAKE_SYSTEM_NAME} MATCHES FreeBSD )
>>   set(CMAKE_BUILD_WITH_INSTALL_RPATH ON)
>> endif()
>>
>> It seems probable that either ld flags aren't being set correctly to
>> indicate that $ORIGIN is in use, or that there's an issue in FreeBSD's
>> handling of $ORIGIN (on at least FreeBSD 9.2).

Hi Rafael - normally I would wait until I had useful information to
post something like this, but I wanted to make sure anyone else who
runs into the same problem is aware that something's up and can work
around it in the short term.

> Which library fails to load?

liblldb - here's what lld shows:

bin/lldb:
        liblldb.so.3.5 => not found (0)
        librt.so.1 => /usr/lib/librt.so.1 (0x80082f000)
        libtinfo.so.5.9 => /usr/local/lib/libtinfo.so.5.9 (0x800a34000)
        <and system and Python-related libraries>

> Is the rpath set correctly?

It looks like it:

feynman% readelf -d bin/lldb | grep PATH
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/../lib]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib]

> Does it work with the configure build?

The buildbot uses the configure build and is green, so it "works" I
guess -- but I do not know if it's using $ORIGIN or an absolute rpath,
and will have to wait until I can complete a configure build locally
to find out.

Ed