Installation issue for ROOT 6.36 RPATHs through Spack on MacOS

[jezwilkinson]

Check duplicate issues.

• Checked for duplicates

Description

Attempting to install ROOT 6.36 via the Spack package manager on MacOS (multiple versions and architectures on different machines) builds without error, but the installation step fails to properly set the RPATH and ROOT is unable to find core libraries when executing or linking other ROOT-based packages.

Runtime error

```
dyld[79397]: Library not loaded: @rpath/libRint.6.36.so
  Referenced from: <27660B66-7EE2-3FB4-9855-E43EF17D9259> /Users/alfaci/jwilkins/spack/opt/spack/darwin-m1/root-6.36.00-s4iedayuyeec6kyav2zahhnvnepvy2gi/bin/root.exe
  Reason: tried: '/private/var/folders/8c/3pr52n2x4ng0j9p3rmqtfyvc0000gn/T/alfaci/spack-stage/spack-stage-root-6.36.00-s4iedayuyeec6kyav2zahhnvnepvy2gi/spack-build-s4ieday/lib/libRint.6.36.so' (no such file) [...]
```

There are also several errors appearing in the install step from install_name_tool, complaining about duplicate entries in the RPATH:

install_name_tool errors

```
error: /Library/Developer/CommandLineTools/usr/bin/install_name_tool: for: /Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/bin/root (for architecture arm64) option "-add_rpath /Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib" would duplicate path, file already has LC_RPATH for: /Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib
error: /Library/Developer/CommandLineTools/usr/bin/install_name_tool: for: /Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/bin/root (for architecture arm64) option "-add_rpath /Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib64" would duplicate path, file already has LC_RPATH for: /Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib64
```

I'm able to fix the issue on my side by patching RootBuildOptions.cmake to revert #18277 which appears for the first time in 6.36 - from some debugging (thanks also to @wdconinc) the issue appears to be some interaction between the gnuinstall flag in ROOT (which is applied by default in Spack), the explicitly set CMAKE_INSTALL_RPATHs from Spack, and the list(APPEND CAKE_INSTALL_RPATH..) in the current version of RootBuildOptions. I've tried adding various different flags to the recipe to fix the issue (e.g. explicitly setting CMAKE_SKIP_INSTALL_RPATH to false), but nothing seems to have helped.
The CMakeCache including the full set of CMake flags invoked by Spack is included under "Additional context"

See spack/spack-packages#215 for more context (Bringing it upstream as there's a chance this also interacts with source building under some combination of flags).

Reproducer

git clone https://github.com/spack/spack   # check out spack package manager
cd spack
source share/spack/setup-env.sh # Set up paths for spack
spack env create testenv  # Create and activate test environment
spacktivate testenv
spack add root@6.36.00 # Add ROOT version to environment spec
spack install # Concretise and install environment
root

ROOT version

6.36.000

Installation method

Package manager (Spack)

Operating system

MacOS: 14.7.6 x86_64 ; 15.5 x86_64 ; 15.5 ARM64

Additional context

CMakeCache.txt

[guitargeek]

Do you have control over the CMAKE_INSTALL_RPATHs from Spack? They seem to be inconsistent with the gnuinstall, as I can see in your CMakeCache.txt:

//No help, variable specified on the command line.
CMAKE_INSTALL_RPATH:STRING=/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib;/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib64

CMAKE_INSTALL_RPATH-CACHED:STRING=/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib;/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-bceszqc7of6ksgxwrbcwya3gjw4vtmwo/lib64

In the case of gnuinstall=ON, the library dir should be lib/root and not lib.

Can you change this in your CMake invocation? Also until, c77bd87, the ROOT build system was overwriting the CMAKE_INSTALL_RPATH passed by the user, if rpath=ON. Now it's appending. So maybe you can set an empty RPATH, to "simulate" the old behavior where ROOT was overwriting it?

[guitargeek]

Anyway, as you also saw in the discussion, there is something wrong in ROOT as well, because it doesn't correctly append its relative RPATH to the INSTALL_RPATH passed by the user.

This PR should fix it:

• [CMake] Append to CMAKE_INSTALL_RPATH with CACHE FORCE #19135

Can you please validate that this patch works for the context of Spack, before we merge it?

[ferdymercury]

Maybe related: https://its.cern.ch/jira/browse/ROOT-9758

[jezwilkinson]

This PR should fix it:

• [CMake] Append to CMAKE_INSTALL_RPATH with CACHE FORCE #19135

Can you please validate that this patch works for the context of Spack, before we merge it?

Thanks very much for the quick response!
I just tried applying that patch, from the CMakeCache it seems the @loader_path paths get correctly added to the CMAKE_INSTALL_RPATH now, but there are still the same errors in the install about duplicated rpaths and they don't get propagated through to the final installation (otool -l $(which root) shows only the "spack/darwin-m1/[package]/lib" paths for all its dependencies as LC_RPATH, while the "old" behaviour added the loader_path ones as extra entries at the end)

CMakeCache:

//Install RPATH
CMAKE_INSTALL_RPATH:STRING=/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-a6hcwb3chua6fxzxj6v2iejglrnqhhpu/lib;/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-a6hcwb3chua6fxzxj6v2iejglrnqhhpu/lib64;@loader_path;@loader_path/../lib/root

CMAKE_INSTALL_RPATH-CACHED:STRING=/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-a6hcwb3chua6fxzxj6v2iejglrnqhhpu/lib;/Users/alfaci/jwilkins/FairSoft_spack_splitrepos/spack/opt/spack/darwin-m1/root-6.36.00-a6hcwb3chua6fxzxj6v2iejglrnqhhpu/lib64

[guitargeek]

Ok, then I don't understand what's going on 🙂 But I'll investigate, since apparently one of my commits caused the problem. It will just take a little while because I need to get my mac mini from the shelf.

[jezwilkinson]

I just tried again explicitly setting the CMAKE_INSTALL_RPATH to lib/root in the spack recipe (not pretty as the prefix/lib and lib64 paths are hard-coded in Spack's cmake build system and can't be changed so will always appear in the build options, but an extra same-named flag at the end as an override).

If I do that, then /lib/root, @loader_path and @loader_path/../lib/root all get added to the executable RPATH as they should (without applying the patch above), along with the root/lib, root/lib64, zlib/lib, [...] that were set at build time due to CMAKE_INSTALL_RPATH_USE_LINK_PATH. In this case the @loader_paths are bit visible in CMakeCache, but this doesn't seem to be an issue.

So as far as I can tell now... it looks like Spack is applying some post-install step to add the RPATHs with install_name_tool, but if the list of install RPATHs has any entries that duplicate something from the LINK_PATH then it refuses to add any of them. But I'm not sure whether this hinges on install_name_tool or on Spack itself (I'm also not normally a Mac user, so not overly familiar with how it handles rpaths normally)