On Thursday 21 February 2008, Brad King wrote: > David Faure wrote: > > I just updated my cmake cvs, (cmake version 2.5-20080220), and I get this > > in kdelibs: > > > > WARNING: Cannot generate a safe runtime path for target kio because there > > is a cycle in the constraint graph: > > dir 0 is [/d/kde/build/4/kdelibs/lib] > > dir 1 is [/d/kde/inst/kdesupport_trunk/lib] > > dir 2 is [/d/kde/src/4/qt-copy/lib] > > dir 3 is [/usr/lib] > > dir 1 must precede it due to [libstreamanalyzer.so] > > dir 2 must precede it due to [libQtSvg.so] > > dir 4 must precede it due to [libacl.so] > > dir 4 is [/lib] > > dir 3 must precede it due to [libbz2.so] > > > > which comes down to: > > > > dir 3 is [/usr/lib] > > dir 4 must precede it due to [libacl.so] > > dir 4 is [/lib] > > dir 3 must precede it due to [libbz2.so] > > > > Which comes from the fact that libacl.so and libbz2.so are not in the same > > system dir, as far as cmake can see. > > But they are: > > ls -l /usr/lib/libbz2.so* > > lrwxrwxrwx 1 root root 18 2007-12-17 17:04 /usr/lib/libbz2.so -> > > /lib/libbz2.so.1.0 > > ls -l /usr/lib/libacl.so > > lrwxrwxrwx 1 root root 14 2007-12-18 20:03 /usr/lib/libacl.so -> > > /lib/libacl.so > > (seems standard on kubuntu gutsy) > > > > Hmm, why does cmake even care for the .so symlinks when looking at runtime > > paths? Runtime only uses .so.1 anyway, not .so... > > > > Ah, but obviously it doesn't look at that, only at what the cache has to > > say: > > CMakeCache.txt:ACL_LIBS:FILEPATH=/lib/libacl.so > > CMakeCache.txt:BZIP2_LIBRARIES:FILEPATH=/usr/lib/libbz2.so > > (because there is no /lib/libbz2.so, only a .so.1) > > > > I'm not sure what the right fix is -- apart from yelling at ubuntu :) > > > > What's for sure is that this is a false positive; any ordering between /lib > > and /usr/lib would work out just fine in this setup. > > Here are some comments: > > 1.) The path ordering should probably always leave system directories > (/lib and /usr/lib) out of the analysis since they will be searched by > default anyway.
Agreed. This would fix my problem already, and make any symlink handling less relevant AFAICS; I ever saw such mess in /lib and /usr/lib, not anywhere else :) > 2.) The reason it gets the false positive is because there is no easy > way to know for sure the soname of a library found on disk (unless > someone can tell me how to do it which would be great). Therefore the > analysis is conservative and assumes that any file starting in the > original name of the library is a possible soname conflict. I guess we > could update this to check if the library is a symlink and assume that > the destination is its soname. What you call soname here is the libfoo.so devel lib? Sorry I forgot what soname really is. Anyway I updated and I saw a commit from you about all this, thanks! The warning seems to be gone now. > 3.) The full fix would be to setup an "imported" library. CMake HEAD in > CVS provides support for importing libraries as logical targets which > allows one to provide more information about a library including its > soname. This solution however requires cooperation from the > distribution providing the library. Not going to happen for libacl.so and libbz2.so I think :) -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem