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