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 _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
