RPATH order problem

[Brad King]

David Faure wrote:
> On Wednesday 02 May 2007, David Faure wrote:
>> On Wednesday 02 May 2007, David Faure wrote:
>>> -L/usr/lib64 
>> is probably the problem. There are many system libs that come from /usr/lib64, but they don't 
>> need -L/usr/lib64 to be added to the link line. This looks very much like a libtool bug I fixed
>> recently in kde3: it was adding -L/usr/lib because it was only filtering out -L/usr/lib64.
>> Here it's the opposite though, it's adding -L/usr/lib64 (but I suppose it's filtering out -L/usr/lib?)
>> On kubuntu systems /usr/lib64 is merely a symlink to /usr/lib; this case should be detected
>> and both -L/usr/lib and -L/usr/lib64 should be removed from the link line (and from the rpaths) IMHO.
> 
> I even get linking errors now, still due to -L/usr/lib64. This might be easier to debug than rpath problems:
> 
> Linking CXX executable kohyphentest
> cd /d/kde/build/4/koffice/libs/kotext/kohyphen && /d/other/inst/bin/cmake -P CMakeFiles/kohyphentest.dir/cmake_clean_target.cmake
> cd /d/kde/build/4/koffice/libs/kotext/kohyphen && /d/other/inst/icecream/bin/c++   -pipe -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions -fno-check-new -fno-common -fno-threadsafe-statics -fvisibility=hidden  -fexceptions -g3 -fno-inline  -fPIC "CMakeFiles/kohyphentest.dir/kohyphentest.o"   -o kohyphentest -rdynamic -L/usr/local/lib -L/d/kde/build/4/koffice/lib -L/d/kde/inst/kde4/lib -L/usr/lib64 -L/d/kde/src/4/qt-copy/lib -L/d/kde/inst/kdesupport_trunk/lib -L/lib64 -lkotext -lkutils -lkofficeui -lflake -lGLU -lGL -lQtOpenGL -lpigment -lkdeui -llcms -lImath -lIlmImf -lIex -lHalf -lkofficecore -lQtCore -lpthread -lkparts -lkstore -lkio -lkabc -lQtCore -lpthread -lkparts -lkio -lkdeui -lQtSvg -lSM -lICE -lX11 -lXext -lXft -lXau -lXdmcp -lXpm -lkdefx -lXtst -lstreamanalyzer -lstreams -lsolid -lQtXml -lkdesu -lkdecore -lfam -lacl -lattr -lkdeprint -lkowmf -lQtNetwork -lQtDBus -lutil -lz -
lbz2 -lresolv -lkdecore -lQtGui -lQt3Support -lQtCore -lpthread -lthreadweaver -lkde3support -Wl,-rpath,/usr/local/lib:/d/kde/build/4/koffice/lib:/d/kde/inst/kde4/lib:/usr/lib64:/d/kde/src/4/qt-copy/lib:/d/kde/inst/kdesupport_trunk/lib:/lib64
> CMakeFiles/kohyphentest.dir/kohyphentest.o: In function `QList<QString>::detach_helper()':
> /d/kde/src/4/qt-copy/include/QtCore/../../src/corelib/tools/qlist.h:500: undefined reference to `QListData::detach2()'
> 
> -> It's finding the QtCore.so from /usr/lib64 because of the order of the -L directives (and that one is older so some symbols are missing).
> I didn't see the usual warning from cmake about "no way to order -L correctly" though.

Thanks for the detailed information.  There seem to be two problems:

1.) The cmOrderLinkDirectories implementation is not detecting the
conflict provided by /usr/lib64.  Would you please provide a list of the
libraries in /usr/lib64 and a list of those in /d/kde/src/4/qt-copy/lib?

2.) The cmLocalGenerator::ComputeLinkInformation method hard-codes a set
of link directories to skip emitting.  Currently it has just "/usr/lib".
 We should probably add "/usr/lib64" to this list also, and it should
probably be converted to a Modules/Platform file variable setting.

-Brad