Add the runfiles directory to the runtime library search paths#14600
Add the runfiles directory to the runtime library search paths#14600EdSchouten wants to merge 1 commit intobazelbuild:masterfrom
Conversation
4d9e0ca to
6583c1d
Compare
6583c1d to
1e781d0
Compare
|
@oquenchil PTAL! |
oquenchil
left a comment
There was a problem hiding this comment.
LGTM. Could you please verify there aren't merge conflicts? Then I will merge.
When executing a C++ binary through REv2 directly (e.g., directly as a genrule, not as a dependency of another script/executable), the input root will only contain a _solib_arch directory inside the executable's runfiles directory. This means that library lookups also need to consider rpath $ORIGIN/$executable.runfiles/$workspace/_solib_$arch/. Only looking at ../../../_solib_$arch/ is not sufficient. This issue isn't noticeable when doing local execution, for the reason that rtld/dyld will first do a realpath() on the executable, meaning the lookup of shared objects takes place outside of the sandbox, inside of bazel-out/ directly. This change extends LibrariesToLinkCollector to duplicate all runtime library search paths. One for bare execution, and one for execution inside a runfiles directory. Change-Id: I4256cb46fee737139aba6f1cfb0531aea5deb315
1e781d0 to
83d2b03
Compare
|
Thanks, @oquenchil! I've just addressed the merged conflicts. Please take another look. |
|
Hey @oquenchil, |
|
No action items for you, @EdSchouten. Our team will merge this. Thanks! |
|
This causes targets to fail internally when there is a Could you please take a look and make sure it takes that into account? |
|
Note that this was rolled back in e898060 due to the breakage above. |
|
@oquenchil Would you have compatibility concerns if we used |
|
On the crosstool? Can you think of any cases where that would break? I'm not familiar with the flag. |
|
Yes, that would be set on the toolchain. GCC and clang support both flags. I know that there are compilers that support |
|
I'm not aware either, so quite possibly out of ignorance no compatibility concerns. |
When executing a C++ binary through REv2 directly (e.g., directly as a genrule, not as a dependency of another script/executable), the input root will only contain a \_solib\_arch directory inside the executable's runfiles directory. This means that library lookups also need to consider rpath $ORIGIN/$executable.runfiles/$workspace/\_solib\_$arch/. Only looking at ../../../\_solib\_$arch/ is not sufficient. This issue isn't noticeable when doing local execution, for the reason that rtld/dyld will first do a realpath() on the executable, meaning the lookup of shared objects takes place outside of the sandbox, inside of bazel-out/ directly. This change extends LibrariesToLinkCollector to duplicate all runtime library search paths. One for bare execution, and one for execution inside a runfiles directory. Closes bazelbuild#14600. Change-Id: I4256cb46fee737139aba6f1cfb0531aea5deb315 PiperOrigin-RevId: 469733573
When executing a C++ binary through REv2 directly (e.g., directly as a
genrule, not as a dependency of another script/executable), the input
root will only contain a _solib_arch directory inside the executable's
runfiles directory. This means that library lookups also need to
consider rpath $ORIGIN/$executable.runfiles/$workspace/_solib_$arch/.
Only looking at ../../../_solib_$arch/ is not sufficient.
This issue isn't noticeable when doing local execution, for the reason
that rtld/dyld will first do a realpath() on the executable, meaning the
lookup of shared objects takes place outside of the sandbox, inside of
bazel-out/ directly.
This change extends LibrariesToLinkCollector to duplicate all runtime
library search paths. One for bare execution, and one for execution
inside a runfiles directory.