Padded install root with trailing os.path.sep doesn't relocate properly

[vanderwb]

Steps to reproduce

I've found that if I build packages in an environment with a padded install root that ends with a separator and then populate a build cache and attempt to install the cached package into a second - unpadded - environment, the RPATH and text-path relocation operations fail because this trailing character is not stripped from the old padded prefix, and so when the old prefix is replaced by the new prefix via a regex, a separating character is lost and an invalid path is produced.

Providing exact instructions to reproduce is difficult, since it will depend on the number of characters in your install root. For me, the following combination in the padded environment spack.yaml produces the issue:

    install_tree:
      root: /glade/scratch/vanderwb/spack/test/build/opt
      padded_length: 126

Meanwhile, for this particular install root, if I use a padded_length of 128 characters it works. See below for the implications.

I found at least two ways to fix the problem, but they basically boil down to rstrip'ing the os.path.sep character from the padded root, as is done for the user-provided root. I could provide a PR for how I've fixed it in our Spack clone, but I'm not sure where it would be best to put the fix. To me, the most logical place is in the parse_install_tree method, but in my testing this does not resolve the problem for already-created cached binary packages. It may be more robust to rstrip the old_layout_root variable in the relocate_package method.

Error message

There is no specific error message, but when using the debug flag and installing a package (spack -d install hdf+shared), a message is provided that demonstrates the trailing-slash issue.

For the 128-character (working) example:

==> [2021-12-28-22:55:31.203264] Relocating package from
  /glade/scratch/vanderwb/spack/test/build/opt/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/__ to /glade/scratch/vanderwb/spack/test/pub/opt.

And from the 126-character (failing) example:

==> [2021-12-28-23:30:11.173922] Relocating package from
  /glade/scratch/vanderwb/spack/test/build/opt/__spack_path_placeholder__/__spack_path_placeholder__/__spack_path_placeholder__/ to /glade/scratch/vanderwb/spack/test/pub/opt.

Finally, if we compare the RPATH's of a relocated library in the second environment, the missing slash problem is obvious.

128-character:

$ readelf -d opt/hdf/4.2.15/gcc/4.8.5/kx64zky/lib/libdf.so | grep RPATH | tr ':' '\n' | grep openssl
/glade/scratch/vanderwb/spack/test/pub/opt/openssl/1.1.1l/gcc/4.8.5/jwr4s44/lib

126-character:

$ readelf -d opt/hdf/4.2.15/gcc/4.8.5/kx64zky/lib/libdf.so | grep RPATH | tr ':' '\n' | grep openssl
/glade/scratch/vanderwb/spack/test/pub/optopenssl/1.1.1l/gcc/4.8.5/jwr4s44/lib
/glade/scratch/vanderwb/spack/test/pub/opt/openssl/1.1.1l/gcc/4.8.5/jwr4s44/lib

I'm not entirely sure why it gets duplicated in the second case, but that does allow it to "work" for libraries. However, the same issue exists for text replacements and this does indeed break things (e.g., the Lmod initialization scripts).

Information on your system

• Spack: 0.17.1-665-9d5ce49
• Python: 3.7.9
• Platform: linux-centos7-cascadelake
• Concretizer: clingo

General information

• I have run spack debug report and reported the version of Spack/Python/Platform
• I have searched the issues of this repo and believe this is not a duplicate
• I have run the failing commands in debug mode and reported the output