kdesupport rpath issues

Rex Dieter rdieter at math.unl.edu
Fri Feb 12 18:25:44 CET 2010


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.  

-- Rex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdelibs-4.3.98-no_rpath.patch
Type: text/x-patch
Size: 1538 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20100212/ad9fbe53/attachment.patch 


More information about the Kde-buildsystem mailing list