cmake cvs and runtime path resolution

[David Faure]

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, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).