cmake cvs and runtime path resolution
brad.king at kitware.com
Thu Feb 21 19:22:09 CET 2008
David Faure wrote:
> On Thursday 21 February 2008, Brad King wrote:
>> 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.
No. The soname is the name used to look for the library at runtime.
Here are the three parts involved:
linkname: libfoo.so -> libfoo.so.3
soname: libfoo.so.3 -> libfoo.so.1.2
Some libraries have just an implementation version:
linkname: libfoo.so -> libfoo.so.4
The soname is needed to determine runtime path order because that is the
name of the file for which the dynamic linker will search. When CMake
does not know the soname it conservatively assumes that the soname is of
the globbing form "libfoo.so*" and adds corresponding constraints.
From the name /path/to/libfoo.so for a third-party library there is no
easy way to reliably detect its soname (which is encoded inside the file
in a native binary format). I'm looking at adding something to guess
that if the file name given is a symlink with no path component that the
symlink points at the soname.
> Anyway I updated and I saw a commit from you about all this, thanks!
> The warning seems to be gone now.
Wow, thanks for testing it so quickly.
More information about the Kde-buildsystem