kdesupport rpath issues

[Rex Dieter]

On 02/12/2010 11:57 AM, Alexander Neundorf wrote:
> On Friday 12 February 2010, Rex Dieter wrote:
>> Maciej Mrozowski wrote:
>>> On Friday 12 of February 2010 16:36:31 Rex Dieter wrote:
>>>> I'm on Fedora 12, using cmake-2.8.0
>>>>
>>>> For me, building many kdesupport items, I end up with binaries and
>>>> libraries that have rpaths containing /usr/lib64 (or /usr/lib on 32
>>>> bit). As I understand it, normal system library paths shouldn't be
>>>> rpath'd.
>>>>
>>>> I've seen this so far trying to build:  akonadi, attica, strigi, soprano
>>>>
>>>> Is this expected?
>>>>
>>>> (At first I thought it to be a generalized cmake problem, but I've also
>>>> tested several other non-kdesupport cmake-based projects without
>>>> problems, including libmusicbrainz, openjpeg, qcomicbook)
>>>
>>> It's expected according to soprano or strigi CMakeLists.txt:
>>
>> ...
>>
>>> It's been put there purposely it seems as a safe default for developers
>>> and alike.
>>> I think you can still disable it if you're sure you install those libs in
>>> standard location in your distribution (say /usr/lib${LIB_SUFFIX)) by
>>> passing -DCMAKE_SKIP_RPATH=ON to cmake.
>>
>> Eww.  OK, we ran into this with FindKDE4Internal.cmake too, and came up
>> with this hackish patch, I'd appreciate if it got some feedback/love from
>> someone with more cmake-fu than I, and we can hopefully get this
>> upstreamed.
>>
>> The intention here is to simply not rpath anything in
>> ${CMAKE_SYSTEM_LIBRARY_PATH}
>> but maybe I'm oversimplifying.
>
> Why do you do this ?
>
> -      set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
> +      set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE)

Not 100% sure, lemme try if it works ok for our purposes without that...

-- Rex