[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: kdesupport rpath issues
From:       Maciej Mrozowski <reavertm () gmail ! com>
Date:       2010-02-12 15:59:00
Message-ID: 201002121659.01130.reavertm () gmail ! com
[Download RAW message or body]

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:

# Set up RPATH handling, so the libs are found if they are installed to a non-
standard location.
# By default cmake builds the targets with full RPATH to everything in the 
build directory,
# but then removes the RPATH when installing.
# These two options below make it set the RPATH of the installed targets to 
all
# RPATH directories outside the current CMAKE_BINARY_DIR and also the library
# install directory. Alex
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_INSTALL_RPATH "${LIB_INSTALL_DIR}")

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.

-- 
regards
MM
_______________________________________________
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
[prev in list] [next in list] [prev in thread] [next in thread]