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