[PATCH] builds libs by default with full RPATH

[Andreas Hartmetz]

Am Donnerstag 20 Dezember 2007 04:53:20 schrieb Michael Pyne:
> On Wednesday 19 December 2007, Andreas Hartmetz wrote:
> > And I might add - why are we using RPATH again? Why are search paths not
> > good enough? Do the advantages really outweigh the disadvantages? If yes,
> > is it still true if all KDE libraries are installed in /usr/lib as all
> > distros do now or will do soon?
>
> The question is what value to use by default for the RPATH setting. 
> Packagers will disable building with RPATH if they don't want it.  So
> AFAICS this setting is most applicable to users building from source (i.e.
> for testing), in which case I think using RUNPATH is the best idea (RPATH
> with
> the --enable-new-dtags linker option to use RUNPATH rather than RPATH).
>
> This way the user can run KDE applications that he builds without needing
> to alter LD_LIBRARY_PATH or /etc/ld.so.conf (and the non-Linux equivalents
> for the BSDs, Solaris, etc.)
>
OK. But even in dev environments it can get in your way, when switching 
between Qt from qt-copy to snapshot for example. I also know now that it's 
easy to disable due to the thread on RPATH on k-c-d.
RPATH looks like it is most useful for people who "just" want to build KDE 
from source and run it without setting up much of an environment around it.
Right?

> Note that if RUNPATH information is present in a executable the
> LD_LIBRARY_PATH is checked first.  If only RPATH tags are present it is
> used regardless of the LD_LIBRARY_PATH setting for backward compatibility.
>
> > Dunno, RPATH looks like an ill-advised hack to me and (IIRC, IMBW,
> > YMMV...) I haven't heard very convincing reasons to use it so far.
>
> It has its uses.  I've named one, I'm sure there are others.
>
It must have been invented for a reason. Some reasons are more reasonable than 
others, though :)

> Regards,
>  - Michael Pyne