Some libraries are not found without LD_LIBRARY_PATH mangling

[Alexander Neundorf]

On Tuesday 30 October 2007, you wrote:
> Em Tuesday 30 October 2007 11:23:27 Alexander Neundorf escreveu:

> > > So, when building a RUN_UNINSTALLED program, it is linked with full
> > > rpath to the build tree and full library list. That way, all libraries
> > > will be found in the build tree, even if the libraries themselves don't
> > > know anything about RUN_UNINSTALLED.
> >
> > Apparently not. If app A links to soprano (or another 3rd party library),
> > and the soprano cmake module just sets
> > SET(SOPRANO_LIBS /opt/soprano/lib/libsoprano.so)
>
> Stop. That's an installed library. It doesn't count.
>
> We're talking about running uninstalled applications that link to
> uninstalled libraries. Linking to installed libraries has never been a
> problem -- the RPATH to the install tree is present anyways.

But not necessarily to RPATH to libraries that library links to, see below.

> > then A will link just to that and not know about other libraries
> > libsoprano.so links to (and their directories, which are required for the
> > RPATH). If libsoprano.so doesn't find its libraries without RPATH (or
> > RUNPATH), there are two options:
>
> Again, stop. libsoprano.so's dependencies are loaded by libsoprano.so
> itself, not by the application. So it's the dependent library's job to find
> the libraries the right way (environment variable, ld.so.conf modification,
> RPATH, whatever).

Yes, we agree here.
What I still don't know is for which steps is the RPATH valid ?

Say APP links to libA, and libA links to libB, and APP has an RPATH, is this 
RPATH also valid for finding libB from libA ?
If yes, why does it fail for Andras ? If I saw it correctly the libraries 
which were not found were also in /opt/kde4/lib64, which was in the RPATH 

> > 1) it needs an RPATH itself
>
> [snip]
>
> > The first option sounds much better to me.
>
> Yes, but that's true of all dependencies, regardless of whether they were
> compiled with CMake or not. So, the point is: we cannot fix a library that
> is already installed. Either it knows how to find its libraries, or
> linking/running will fail. In any case, it's not our fault.

Yes, but for anything except kdelibs any library from kdelibs is an "already 
installed library". Currently they don't get an RPATH at all (except with 
FULL_RPATH option), but when linking to them the full list of libs is used 
(which should produce the correct RPATH for the executable). 
Once the libraries get an RPATH, they already have it in the build tree or 
they will be relinked.

...
> Well, then I'm ready to say our Windows support is "shaky at best" and
> running the tools may fail at any time, including during compilation.

I don't see why they should fail during compilation. Batch files which set the 
PATH are executed (as there are shell scripts executed under Unix).

> If we're going to place files in their correct places only starting with KDE
> 4.1, then we're tabling this discussion.

It will be our first Windows release ever, so I don't expect that it will be 
production-quality. Same for OS X. We discussed, but didn't get to a good 
solution, in some cases the discussion just stopped when I asked for some 
change.

...
> > > - on ELF platforms without DT_RUNPATH (IRIX, HP-UX):
> > >   RUN_UNINSTALLED executables are relinked at install time
> >
> > This could make some things easier, I think we could even completely get
> > rid of the RUN_UNINSTALLED argument. Everything, apps and libs would get
> > the full RPATH (RUNPATH) for the install tree, the shell scripts which
> > set LD_LIBRARY_PATH are created anyway.
>
> That's what I proposed for the platforms using DT_RUNPATH. But mind you:

So we agree, right ?

> the real target (the ELF executable) should have a different name -- the
> shell script should have the target's name inside the build tree.

I don't feel like changing this now and I don't see a real reason for it. The 
shell script is currently <target>.shell, if you use tab completion you 
notice that there are two executables.

> > P.S. actually the platform is intended to be frozen, and this is a
> > significant change...
>
> Things are working fine as-is for me, using the FULL_RPATH option. Almost
> no one has complained about this problem for the several months since we've
> last discussed RPATH.

Yes, FULL_RPATH is ok, my only problem is the time the relinking takes. It's 
even better than RUNPATH+LD_LIBRARY_PATH (because you can run it directly and 
don't have to use a script).
I'll put chrpath on my TODO.

Alex