-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix rpath for binaries in external repositories #16008
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? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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