cmake news: RPATH

[David Faure]

On Thursday 23 March 2006 01:21, Brad King wrote:
> >>"both" - (not on OS X)
> I really don't like this option. 
Me neither. Alex, can we remove it?

> FYI, I anticipated this dilemma and provided a "preinstall" target that 
> can be built by the user to do the relinking before changing to root:
> 
> make && make preinstall && sudo make install

Interesting workaround. Any change to the usual make && [sudo] make install
will remain an obscure workaround though, since nobody would even guess that
there is such a solution :)

> As described below, relinking should only be needed for developers that 
> want to run applications from the build tree but still install from the 
> same tree.
Right, this is why "default" is a rather bad default, given that most KDE applications
do *not* support running from the build tree at this point. (I mean the real GUI apps).

> 1.) Executables that are not run during the build but are installed.
> 2.) Executables that are run during the build and not installed.
> 3.) Executables that are run during the build and are installed.

Excellent analysis. Indeed we need to do things differently for those 3 kinds.

> -------------------------------------------------------------------------
> For #1 there is a choice for developers and a choice for users.  Setting 
> the target property BUILD_WITH_INSTALL_RPATH will cause the executables 
> to get built with an RPATH meant for the install tree.  No relinking is 
> needed for installation but the executables will not run from the build 
> tree (except on RUNPATH platforms with LD_LIBRARY_PATH set properly). 
> This is the choice for users and should be the default.
For now it would be a good default for developers too, as long as running from
the builddir isn't really supported. It's good to have the option for later, of course.

> -------------------------------------------------------------------------
> For #3 there is potential trouble.  When running from the build tree we 
> need to make sure the build tree libraries are used, and when running 
> from the install tree we need to make sure the install tree libraries 
> are used.
> 
> If BUILD_WITH_INSTALL_RPATH is set on a non-RUNPATH platform and there 
> is an existing old install the wrong libraries will be used when running 
> during the build.  Even on a RUNPATH platform the environment must have 
> the proper LD_LIBRARY_PATH for the build tree.
Nobody sets LD_LIBRARY_PATH to point to the build tree during compilation;
wrapper scripts would have to do that.

> If BUILD_WITH_INSTALL_RPATH is not set then relinking is required for 
> installation even for users.  Everyone would have to do "make 
> preinstall" as described above.
This is not an option IMHO.

> There are a few ways to resolve this problem:
> 
>    a.) Link these executables statically and build into them all the 
> sources they need.  Then no RPATH is needed at all.  Since executables 
> run during the build tend to be small generators this may not be too bad.
But then we need to actually generate a static version of libkdecore.... Hmm.

>    b.) Do not set BUILD_WITH_INSTALL_RPATH, document it for users, and 
> live with the relinking.  Since executables run during the build tend to 
> be small generators relinking is not too slow.
Yes, for only two binaries (see below) it would be fine. But having to teach
everyone to use make preinstall, doesn't make this option worth it.

>    c.) Enable the SKIP_BUILD_RPATH target property and set the 
> INSTALL_RPATH property to empty.  This will remove RPATHs completely 
> from these executables.  Then wrap them in a shell script or a 
> forwarding executable like that described for option 2 in
>   http://mail.kde.org/pipermail/kde-buildsystem/2006-January/000445.html
> Option (c) is a pain to setup the first time but will work very well if 
> there are only a few such executables.
Yes it sounds good to me.

> -------------------------------------------------------------------------
> 
> The decision for #3 may depend on the number, size, and role of such 
> executables.  Can anyone respond and enumerate them please?

I see the following (the sizes include debug symbols):

kconfig_compiler - 637K here, creates .cpp/.h from a .kcfg (+.kcfgc) file, links to QtCore+QtXml only, so no rpath problem!
makekdewidgets - 264K here, creates a .cpp (designer plugin) from a ini-style description file of widgets. Links to kdecore.
meinproc - 305K here, compiles .docbook files, is run in kdelibs/doc. Links to kdecore.
dcopidl2cpp - 417K here, creates a .cpp/.h from a .kidl file (DCOP interface description), links to QtCore+QtXml only.
  (might disappear before KDE4, too)

Note:
genembed - 192K here, generates code that contains pixmaps. is NOT installed.
genshortcutents - 125K here, generates entities from the system-default shortcuts, for the documentation. is NOT installed.
dcopidl - is perl :)

Summary: only makekdewidgets and meinproc are binaries that are run during 
kdelibs compilation and are installed, and link to a kdelibs library.
Option c) sounds very sensible.

(if you're looking for them in the sources, makekdewidgets is under kdewidgets/,
and meinproc is under kdoctools/).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).