[CMake] How to avoid the explicit library location when linking with imported library targets
Pere Mato Vila
Pere.Mato at cern.ch
Fri Sep 17 11:24:50 EDT 2010
>> The problem I have is that when have already built and
>> installed B I can not move anymore the location of the A. This
>> is because the libraries created in B contains the absolute
>> path to exported libraries in A.
>
> The binaries in B would at most contain RPATH entries to point at the
> location of A. CMake computes this RPATH information to ensure that
> the binaries can run without special environment variables by default.
> This works on the original machine. If you want to redistribute the
> binaries then you have to tell CMake not to store RPATH information.
> This is totally separate from whether the libraries are handed to the
> linker by full path or not.
What I observe is that the library which is built using an imported library target keeps the full path of it in the build directory and in the installation directory. I can see this with the ldd command in the build and installation tree:
$ ldd libLHCbMathLib.so
/build/mato/GAUDI/GAUDI_v21r10p1/InstallArea/x86_64-slc5-gcc43-opt/lib/libGaudiKernel.so (0x00002afdec07d000)
libGenVector.so => /afs/cern.ch/sw/lcg/app/releases/ROOT/5.26.00cp1_python2.5/x86_64-slc5-gcc43-dbg/root/lib/libGenVector.so (0x00002afdec5bd000)
libgsl.so.0 => /afs/cern.ch/sw/lcg/external/GSL/1.10/x86_64-slc5-gcc43-opt/lib/libgsl.so.0 (0x00002afdecaa2000)
libstdc++.so.6 => /afs/cern.ch/sw/lcg/external/gcc/4.3/x86_64-slc5/lib64/libstdc++.so.6 (0x00002afdece81000)
libm.so.6 => /lib64/libm.so.6 (0x00002afded1a1000)
...
$ ldd /build/mato/LHCB/LHCB_v31r4/InstallArea/x86_64-slc5-gcc43-opt/lib/libLHCbMathLib.so
/build/mato/GAUDI/GAUDI_v21r10p1/InstallArea/x86_64-slc5-gcc43-opt/lib/libGaudiKernel.so (0x00002b6564776000)
libGenVector.so => not found
libgsl.so.0 => not found
libstdc++.so.6 => /afs/cern.ch/sw/lcg/external/gcc/4.3/x86_64-slc5/lib64/libstdc++.so.6 (0x00002b6564cd0000)
libm.so.6 => /lib64/libm.so.6 (0x00002b6564fd7000)
...
The "not found"s is normal since the CMake installation has removed the RPATH information. However still remains the full path of the imported library 'libGaudiKernel.so'. The problem is that I cannot reproduce it with a small set of projects. They behave as you have described, that is, the RPATH information is present in the build tree and then is removed when installed. Do you have an idea what this direct reference of the imported library is?
-------------------------------------------------------------
Pere Mato CERN, PH Department, CH 1211 Geneva 23, Switzerland
e-mail: pere.mato at cern.ch tel: +41 22 76 78696
fax: +41 22 76 68792 gsm: +41 76 48 70855
More information about the CMake
mailing list