diff options
| author | Harmen Stoppels <harmenstoppels@gmail.com> | 2022-10-21 18:30:26 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-10-21 18:30:26 +0200 |
| commit | f9112a6244dede4d52700c4e86f335b42ec69a49 (patch) | |
| tree | 99c7ccdf0f87759c8b6cc7778937d8e393af5a43 /share | |
| parent | 7c3d93465c1d76e084d6b0ce4a44d1c0b4b1ae68 (diff) | |
| download | spack-f9112a6244dede4d52700c4e86f335b42ec69a49.tar.gz spack-f9112a6244dede4d52700c4e86f335b42ec69a49.tar.bz2 spack-f9112a6244dede4d52700c4e86f335b42ec69a49.tar.xz spack-f9112a6244dede4d52700c4e86f335b42ec69a49.zip | |
Relocation should take hardlinks into account (#33460)
Currently `relocate_text` and `relocate_text_bin` are unsafe in the
sense that they run in parallel, and lead to races when modifying
different items pointing to the same inode.
This leads to the issue observed in #33453.
This PR:
1. Renames those functions to `unsafe_*` so people are aware
2. Adds logic to deal with hardlinks in current binary packages
3. Adds logic to deal with hardlinks when creating new binary tarballs,
so the install side doesn't have to de-dupe hardlinks.
4. Adds a test for 3
The assumption is that all our relocation logic preserves inodes. That
is, we should never copy a file, modify it, and then move it back. I
quickly verified, and its seems like this is true for (binary) text
relocation, as well as rpath patching in patchelf (even when the file
grows) and mach-o fixes.
Diffstat (limited to 'share')
0 files changed, 0 insertions, 0 deletions