cmake cvs and runtime path resolution

Brad King 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
   realname:  libfoo.so.1.2

Some libraries have just an implementation version:

   linkname:    libfoo.so -> libfoo.so.4
   real/soname: 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.

-Brad


More information about the Kde-buildsystem mailing list