Branch: refs/heads/master
Home: https://github.com/xrootd/xrootd
Commit: 73f39dc2d9a06f6bf3da2075d6cade6c24a1866a
https://github.com/xrootd/xrootd/commit/73f39dc2d9a06f6bf3da2075d6cade6c24a1866a
Author: Paul Millar <[log in to unmask]>
Date: 2021-01-05 (Tue, 05 Jan 2021)
Changed paths:
M src/XrdUtils.cmake
Log Message:
-----------
XrdUtils: add suitable RUNPATH to build-tree library
Motivation:
cmake supports building executables and shared libraries so that they
may be run directly from the build tree. This is useful as it
simplifies and speeds up development work by allowing code to be tested
immediately after building the binaries; i.e., without any installation
step.
As part of this support, cmake will build libraries and executables so
that the ELF metadata contains either an RPATH (on older/non-Linux
systems) or RUNPATH (on newer/Linux systems) that tells the system's
linker to also look for shared libraries in the build tree. This allows
dynamic link loading to find libraries located within the build tree.
Note that cmake will remove the RPATH or RUNPATH elements by relinking
executables or libraries as part of the 'install' target. Although such
paths are likely harmless if distributed, the presence of the build path
as RPATH/RUNPATH metadata is a potential source of confusion for
developers.
Unlike RPATH, the newer RUNPATH path does not resolve transitive
dependencies. As a specific example, the RUNPATH of 'xrdcp' is used to
resolve the XrdUtils library (libXrdUtils.so), but this xrdcp RUNPATH
path is then not used when XrdUtils wishes to resolve dynamic libraries,
such as XrdSecgsi-5 (libXrdSecgsi-5.so). Instead, the expectation is
that the XrdUtils library itself contains any necessary RUNPATH path.
For this specific example, the XrdUtils library located within the build
tree should contain a RUNPATH path so that it may find XrdSecgsi-5 when
loaded by xrdcp, also located within the build tree.
For the most part, cmake takes care of adding such RUNPATH paths
automatically. When cmake knows a target (e.g., xrdcp) depends on some
other target (XrdUtils) then it adds the corresponding RUNPATH entry in
the build-tree binary. However, cmake does not know that XrdUtils will
load other libraries, so it does not add the corresponding RUNPATH path.
The result is that, although it is currently possible to run programs
like 'xrdcp' and 'xrdfs' directly from the build tree, doing so may not
work as intended. The command may fail (e.g., due to the apparent lack
of GSI authentication support) or the build-tree XrdUtils will use
libraries installed in a standard system location (e.g. /usr/lib), which
may yield spurious results.
Modification:
Add the BUILD_RPATH property to the XrdUtils target, so ensuring the
build-tree XrdUtils library contains the necessary RUNPATH. When
installing, the XrdUtils library will now be relinked (to remove this
RUNPATH).
Note that support for the BUILD_RPATH property was added with cmake
v3.8. The change in this patch has no effect when the code is built
with cmake v3.7 or earlier.
Also recall that cmake will remove this RUNPATH location when
installing. Therefore, the final library is unaffected by this change.
Result:
Commands like 'xrdcp' and 'xrdfs' may now be run from within the
build-tree.
Commit: 29ea6c483b91c135d282ba07b1bbefcb1d3a3a6f
https://github.com/xrootd/xrootd/commit/29ea6c483b91c135d282ba07b1bbefcb1d3a3a6f
Author: simonmichal <[log in to unmask]>
Date: 2021-01-07 (Thu, 07 Jan 2021)
Changed paths:
M src/XrdUtils.cmake
Log Message:
-----------
Merge pull request #1374 from paulmillar/development/add-xrdutils-build-runpath
XrdUtils: add suitable RUNPATH to build-tree library
Compare: https://github.com/xrootd/xrootd/compare/816f8de60737...29ea6c483b91
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|
