Some libraries are not found without LD_LIBRARY_PATH mangling

[Alexander Neundorf]

On Monday 29 October 2007, Thiago Macieira wrote:
> Em Monday 29 October 2007 15:27:42 Alexander Neundorf escreveu:
...
> > Ok. If we build libraries always with RPATH, this means all libraries
> > have to be built always with the RPATH for the build tree and then need
> > to be linked again when installing with the RPATH for the install tree.
> > This will make "make install" slower.
> >
> > If we don't do this, then programs which are intended to run from the
> > build tree will find the libraries from their own RPATH (pointing into
> > the build tree), e.g. kdeui, but kdeui would already have the RPATH for
> > the install tree, which would be e.g. /opt/kde4/lib, so it might pick up
> > an older version of libkdecore.
> > So, it seems all libraries need to be relinked.
> >
> > Did I miss something ?
>
> No, you're not.
>
> But can't we use the installed libraries for the commands used during
> installation?

You mean "used during building", right ? 
Not necessarily. The commands may use some new stuff or need bug fixes from 
the libs so they need to get the libraries from the build tree.

> Another option: build those tools only with RPATH to the build tree, then
> relink them (and only them) during installation. This requires a full
> library list during linking: e.g., "-lkio -lkdeui -lkdecore", not just
> "-lkio". Doesn't CMake already do that?

Well, the issue is that potentially any of the libraries could be used by 
these tools, and it doesn't make sense to mark libraries as RUN_UNINSTALLED, 
because the developer of the library doesn't necessarily know that.

CMake doesn't automatically detect which shared libraries are linked to 
executables which have an RPATH which points into the build tree, in order to 
guess to build these libraries also with RPATH pointing into the build tree. 

> Maybe an even better option: set LD_LIBRARY_PATH when running uninstalled.
> That variable overrides RUNPATH and any distribution not using that (read:
> using RPATH only) should be shot in the head. DT_RUNPATH has been available
> for more than 5 years.

While it probably is available on most Linux systems today, I don't know if 
this is also true for *BSD, Solaris, HP-UX etc. 
I don't think CMake right now supports setting only RUNPATH but not RPATH due 
to this. Even if it would be implemented today, it wouldn't help us since we 
require CMake 2.4.5 for KDE 4.0.x.

Having something like install_name_tool would be nice :-)
There is chrpath but this is not widely installed and works only if the new 
RPATH is not longer than the original one, so it would need some support from 
the linker, so enough space is reserved. OS X does that.

Alex