[CMake] RPATH questions

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Jul 24 19:39:22 EDT 2006


On 2006-07-24 13:22-0700 Alan W. Irwin wrote:

> On 2006-07-24 11:14-0400 Brad King wrote:
>
>> If you don't set BUILD_WITH_INSTALL_RPATH or SKIP_BUILD_RPATH properties
>> then the modules built into the build tree will have the proper rpath to
>> load from there.
>
> Thanks for that useful information which I have just confirmed.  I have also
> just confirmed that the rpath properties propagate in the build tree without
> any special intervention.  What I mean by that is I have two target
> libraries: libplplotcxxd which depends on libplplotd but which has no
> direct dependend on libltdl, and libplplotd which
> depends on libltdl in a special location.  Here are the ldd results:
>
> ldd bindings/c++/libplplotcxxd.so
>        libplplotd.so.9 => 
> /home/software/plplot_cvs/HEAD/build_dir/src/libplplotd.so.9 (0xb7fa2000)
>        libltdl.so.3 => /home/software/autotools/install/lib/libltdl.so.3 
> (0xb7f9b000)
> 	...
>
> ldd src/libplplotd.so
>        libm.so.6 => /lib/tls/libm.so.6 (0xb7f7b000)
> 	libltdl.so.3 => /home/software/autotools/install/lib/libltdl.so.3 
> (0xb7f73000)
> 	...
>
> So all is well in the build tree, [...]

Well, there is one caveat (which turns out to be the source of most of my
confusion in this area).  If you find your external library using
FIND_LIBRARY and pass that result to TARGET_LINK_LIBRARIES, then Brad's
assertion that you don't have to do anything special in the build tree with
RPATH is correct.  That is what I did above, and that is why I got a good
result.  BTW, when you print out that result on Linux it is the complete
path + filename, e.g., /home/software/autotools/install/lib/libltdl.so.
However, if you use PKGCONFIG (which I must use to find dependencies of
another target for my PLplot project), that returns library locations as a
combination of -L and -l options.  When those are passed to
TARGET_LINK_LIBRARIES, the link step occurs without errors but the rpath
information for the external library is dropped in the build tree.
Presumably this occurs because those -L and -l flags are just passed
directly to the linker without any RPATH interpretation by
TARGET_LINK_LIBRARIES.

The workaround for this PKGCONFIG build-tree RPATH issue is to follow each
PKGCONFIG step with FIND_LIBRARY using the PATH information determined by
PKGCONFIG.  This puts the result in a form that TARGET_LINK_LIBRARIES can
interpret correctly with respect to RPATH.

_Then_, all is well in the build tree with regard to RPATH with no special
intervention required.

Thanks, Brad, for your responses to my comments and questions including your
recent confirmation that I am going to have to apply INSTALL_RPATH for every
target that depends on my main library. You have been most helpful.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list