cmake cvs and runtime path resolution

[Brad King]

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