Remove RPATH for UPS installations

[knoepfel]

In this issue, the PRODUCTS (and therefore LD_LIBRARY_PATH) environment variables contained a few directories, all of which contained ROOT installations:

PRODUCTS=/mu2e/ups:/cvmfs/fermilab.opensciencegrid.org/products/artdaq:/cvmfs/mu2e.opensciencegrid.org/artexternals`

Note that the KinKal UPS product was in /cvmfs/mu2e.... Because KinKal uses RPATH in its installation (see https://github.com/KFTrack/KinKal/blob/main/CMakeLists.txt#L104:L106), whenever a KinKal library is loaded, any library that can be found on the specified rpath will be favored over any libraries that have already been loaded via LD_LIBRARY_PATH. This results in a mixed environment, where (technically speaking) the one-definition rule is violated.

In the aforementioned issue, the sequence of events is the following:

• ROOT libraries are loaded from /mu2e/ups
• KinKal is loaded from /cvmfs/mu2e...
• KinKal library favors /cvmfs/mu2e... installation of ROOT because of presence of rpath.
• Now we have a mixture of libraries from /mu2e/ups and /cvmfs

resulting in the failure seen in that issue.

To fix this problem, we suggest removing RPATH from the installation of KinKal. This is achievable via the following replacement:

- # set RPATH options
- set(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/lib)
- set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
+ set(CMAKE_SKIP_INSTALL_RPATH ON)

[kutschke]

@brownd1978 How do you to proceed with this? One option is to follow Kyle's advice; that might affect your standalone test suite. The other option is to branch in the cmake file and do it the original way for non-Mu2e builds and Kyle's way for builds destined for Mu2e installs.

[brownd1978]

I’ll have a look at this tomorrow. I’m not fluent with ups and don’t recall all the details how rpath was used for KinKal. I’m not averse to following Kyles advice, so long as it doesn’t impact performance.

On Wed, Jan 11, 2023 at 15:26 Rob Kutschke ***@***.***> wrote: @brownd1978 <https://github.com/brownd1978> How do you to proceed with this? One option is to follow Kyle's advice; that might affect your standalone test suite. The other option is to branch in the cmake file and do it the original way for non-Mu2e builds and Kyle's way for builds destined for Mu2e installs. — Reply to this email directly, view it on GitHub <#166 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH576NX4BIYTHFCD5JIATWR46SLANCNFSM6AAAAAATYRRFBY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- David Brown ***@***.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[brownd1978]

Resolved with release v2.3.0