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