Fix rpath for binaries in external repositories#16008
Fix rpath for binaries in external repositories#16008fmeum wants to merge 2 commits intobazelbuild:masterfrom
Conversation
|
@oquenchil This PR is similar to #14600, but resolves a different issue. I can rebase this PR onto #14600 if you should prefer to merge that one first. |
The solib directory is located within the subdirectory of the runfiles directory corresponding to the workspace. Thus, if a binary is contained in an external repository, its $ORIGIN relative rpath has to first ascend to the runfiles directory and then descend into the workspace directory.
5d1abde to
8dd6376
Compare
|
@bazel-io flag |
|
Success, this fixes test in external repositories! Thanks @fmeum ! |
|
@bazel-io fork 5.3.0 |
1 similar comment
|
@bazel-io fork 5.3.0 |
|
@kshyanashree The command lacks the rc1. |
|
@bazel-io fork 5.3.0rc1 |
|
@kshyanashree I don't know why, but the last command failed as well. |
|
Assigning to @oquenchil since this is about cc rules. |
|
@bazel-io fork 5.3.0 |
|
Hi @fmeum, Is it possible for you to get the PR review done? Since we will be merging it under the release 5.3.0. |
|
@kshyanashree I don't know when @oquenchil will be able to review the change. It does fix a known Bazel 5 regression - is that sufficient to hold the release for it/up the priority? |
The solib directory is located within the subdirectory of the runfiles directory corresponding to the workspace. Thus, if a binary is contained in an external repository, its $ORIGIN relative rpath has to first ascend to the runfiles directory and then descend into the workspace directory. Fixes bazelbuild#16003 Closes bazelbuild#16008. PiperOrigin-RevId: 466634083 Change-Id: I4ada28b459f23f68a2091dbaad9147cfec2fbe43
The solib directory is located within the subdirectory of the runfiles directory corresponding to the workspace. Thus, if a binary is contained in an external repository, its $ORIGIN relative rpath has to first ascend to the runfiles directory and then descend into the workspace directory. Fixes #16003 Closes #16008. PiperOrigin-RevId: 466634083 Change-Id: I4ada28b459f23f68a2091dbaad9147cfec2fbe43
|
Although this patch fixes the remote execution case, it breaks the local execution case. In local execution, the runfiles tree contains symlinks to regular files in the output root; the $ORIGIN that the dynamic loader uses is the location of that regular file, not the symlink: and the solib directory is directly underneath This causes the test to fail: |
|
CC @kshyanashree as a potential 5.3.0 regression. @pcjanzen Would adding both rpaths fix this problem? |
I think so, but between this problem and #14600 there are starting to be kind of a lot of rpath entries and I can't honestly say I've thought through all the combinations. |
The fix for remote execution of external dynamically linked cc_* targets in 95a5bfd regressed local execution of such targets. This is fixed by emitting two rpaths in the case of an external target. Fixes #16008 (comment) Closes #16214. PiperOrigin-RevId: 473706330 Change-Id: I500f8b1f79e4d994323651fbb5964a730f1136e3
The fix for remote execution of external dynamically linked cc_* targets in 95a5bfd regressed local execution of such targets. This is fixed by emitting two rpaths in the case of an external target. Fixes bazelbuild#16008 (comment) Closes bazelbuild#16214. PiperOrigin-RevId: 473706330 Change-Id: I500f8b1f79e4d994323651fbb5964a730f1136e3
The fix for remote execution of external dynamically linked cc_* targets in 95a5bfd regressed local execution of such targets. This is fixed by emitting two rpaths in the case of an external target. Fixes bazelbuild#16008 (comment) Closes bazelbuild#16214. PiperOrigin-RevId: 473706330 Change-Id: I500f8b1f79e4d994323651fbb5964a730f1136e3
The fix for remote execution of external dynamically linked cc_* targets in 95a5bfd regressed local execution of such targets. This is fixed by emitting two rpaths in the case of an external target. Fixes bazelbuild#16008 (comment) Closes bazelbuild#16214. PiperOrigin-RevId: 473706330 Change-Id: I500f8b1f79e4d994323651fbb5964a730f1136e3
The fix for remote execution of external dynamically linked cc_* targets in 95a5bfd regressed local execution of such targets. This is fixed by emitting two rpaths in the case of an external target. Fixes bazelbuild#16008 (comment) Closes bazelbuild#16214. PiperOrigin-RevId: 473706330 Change-Id: I500f8b1f79e4d994323651fbb5964a730f1136e3
The fix for remote execution of external dynamically linked cc_* targets in 95a5bfd regressed local execution of such targets. This is fixed by emitting two rpaths in the case of an external target. Fixes #16008 (comment) Closes #16214. PiperOrigin-RevId: 473706330 Change-Id: I500f8b1f79e4d994323651fbb5964a730f1136e3 Co-authored-by: kshyanashree <109167932+kshyanashree@users.noreply.github.com>
The fix for remote execution of external dynamically linked cc_* targets in 95a5bfd regressed local execution of such targets. This is fixed by emitting two rpaths in the case of an external target. Fixes bazelbuild#16008 (comment) Closes bazelbuild#16214. PiperOrigin-RevId: 473706330 Change-Id: I500f8b1f79e4d994323651fbb5964a730f1136e3
The solib directory is located within the subdirectory of the runfiles
directory corresponding to the workspace. Thus, if a binary is contained
in an external repository, its $ORIGIN relative rpath has to first
ascend to the runfiles directory and then descend into the workspace
directory.
Fixes #16003