[CMake] How to avoid the explicit library location when linking with imported library targets

[Brad King]

On 09/17/2010 12:31 PM, Pere Mato Vila wrote:
> Thanks for your interest.  In fact your questions made me think
> in the direction that the problem must be in the way the
> library libGaudiKernel.so was built or installed. In fact I
> remembered that I have a soft link in the installation
> path. The directory /build/mato/GAUDI/GAUDI_v21r10p1 is a soft
> link to /build/mato/GAUDI/GAUDI_cmake and the library was
> actually installed in
> /build/mato/GAUDI/GAUDI_cmake/InstallArea/x86_64-slc5-gcc43-opt/lib. So
> if I change the path in the link statement then I do get the
> expected ldd output.  What I learn with this is that your claim
> that the install tree can be relocated to a new prefix and will
> still work is not true if this new location has a soft link.

I think this case is potentially more subtle than that.  See below.

> My original question remains valid. Why to use the absolute
> path for the imported library instead of using the -l?

CMake 2.4 and lower used to *always* split a full path to a
library into separate -L and -l options.  This led to endless
problems with the -l search not picking up the intended library.
Starting with CMake 2.6 we (almost) always preserve full paths.
Since then we've had no problems with the wrong library getting
linked.

Generally when the linker is given a path like

  /path/to/lib/libfoo.so

it opens the file, looks for the SONAME field, and copies that
into the resulting binary.  At runtime the dynamic loader searches
for the library using this SONAME.  Usually the SONAME is just a
file name to be located by looking through the RPATH and whatever
appears in LD_LIBRARY_PATH.

However, if the "libfoo.so" file does not have any SONAME field
then the behavior of the linker is less clear.  Sometimes it will
just copy in the full path to the file.  See here:

  http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmComputeLinkInformation.cxx;hb=v2.6.4#l218

This is why I was asking all those questions.  I bet the library
has not been built with a proper SONAME field.

CMake does try to detect when there is no SONAME and will use -l
to avoid this problem.  In the case of an imported target it checks
for the IMPORTED_NO_SONAME property:

  http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmTarget.cxx;hb=v2.6.4#l3565

Try setting that for your imported target (to value "1").  It looks
like this property is missing from the documentation though!  I'll
fix that.

-Brad