-
-
Notifications
You must be signed in to change notification settings - Fork 723
Compute rpath correctly with nested bazel modules #4390
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
Conversation
0957235 to
a1d452b
Compare
fmeum
left a comment
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.
Functionally looks good to me, just a few stylistic comments.
fmeum
left a comment
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.
I applied minor edits that inline the new variables to keep the diff small. I hope you don't mind :-)
Previous code was assuming that both the binary and the shared library are present under the working directory. This assumption is violated for a repo with nested modules. The fix is to compute rpath relative to the runfiles directory.
ab37811 to
7cfc71c
Compare
What type of PR is this?
Bug fix
What does this PR do? Why is it needed?
My company has a complicated, uncommon bazel set up with nested bazel modules. We also use cgo extensively and have many go tests and binaries that end up linking to shared C++ libraries generated via other bazel modules. When such go tests are run with rbe, they fail due to failure to locate the shared libraries within the runfiles directory.
On deeper investigation, I found that the existing
rpathcomputation assumes that both the executable and the library are present within the working directory. In reality, the executable is present outside the working directory but within the runfiles directory.Normalizing the paths with respect to the runfiles directory fixes the issue.
Relevant links:
Other notes for review
I added a test to verify that rpath computation works with nested modules. In fairness, this mainly guarantees that there's no regression in existing functionality as the test passes even without my fix. So far, I've not been able to produce a minimum example that showcases the problem.
Existing tests in tests/core/cgo also exercise rpath computation.