RPATH order problem

[David Faure]

On Friday 04 May 2007, you wrote:
> David Faure wrote:
> > I also updated cmake from cvs before patching it to add debug output, so maybe there was
> > a cmake fix meanwhile that fixed the issue?
> 
> If there was such a fix it was probably an accident.  I do not know of
> any intentional change for a problem like this.  The patches I've sent
> were against CMake 2.4, so I guess it is just luck that they worked for
> CVS CMake too.
> 
> Either way we should probably still ban /usr/lib64 from appearing with
> -L or in an rpath.  If I commit this change you may need to comment it
> out again to continue trying to reproduce the original problem.

OK I know how it happened: by installing libqt4-dev into /usr _after_ having configured kdelibs and kdebase.
So there was no conflict when they were initially configured (and CMakeCache written out),
but the conflict appeared later on. And even though the configuration step surely
reran multiple times since then, some cache must have kept the wrong order of things.

I can reproduce this with a different lib easily.
I compile the target kohyphentest (in koffice), it uses the following lib order:
 -L/usr/local/lib -L/d/kde/build/4/koffice/lib -L/d/kde/inst/kde4/lib -L/d/kde/src/4/qt-copy/lib -L/usr/lib64 -L/d/kde/inst/kdesupport_trunk/lib -L/lib64
and the -lqca is resolved to /d/kde/inst/kdesupport_trunk/lib/libqca.so (which is libqca.so.2). No problem yet.

Now I install libqca.so into /usr/lib using a package from my distribution, and
when relinking kohyphentest I get:
/usr/bin/ld: warning: libqca.so.2, needed by /d/kde/build/4/koffice/lib/libkotext.so, may conflict with libqca.so.1
which is logical, since now -lqca resolves to /usr/lib64/libqca.so (which is libqca.so.1).

If I now force a reconfiguration (touch CMakeLists.txt ; cmake) I see:

Determining link dir order for target kohyphentest
Checking [/d/kde/inst/kdesupport_trunk/lib/libqca.so] conflict at [/usr/lib64/libqca.so]: yes (file)
no
this->DirectoryToAfterList
/usr/local/lib:
/d/kde/build/4/koffice/lib:  /d/kde/inst/kde4/lib /d/kde/inst/kde4/lib /d/kde/inst/kde4/lib /d/kde/inst/kde4/lib /d/kde/inst/kde4/lib /d/kde/inst/
kde4/lib /d/kde/inst/kde4/lib
/d/kde/inst/kde4/lib:
/usr/lib64:
/d/kde/src/4/qt-copy/lib:  /usr/lib64 /usr/lib64 /usr/lib64 /usr/lib64 /usr/lib64 /usr/lib64 /usr/lib64 /usr/lib64
/d/kde/inst/kdesupport_trunk/lib:  /usr/lib64
/lib64:

and the target is linked with
-L/usr/local/lib -L/d/kde/build/4/koffice/lib -L/d/kde/inst/kde4/lib -L/d/kde/src/4/qt-copy/lib -L/d/kde/inst/kdesupport_trunk/lib -L/usr/lib64 -L/lib64
which is completely correct.

==> There is no bug with the link dir ordering code, AFAICS.
It would just be much simpler if -L/usr/lib64 and -L/lib64 were never generated.

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