Solution for building without sandbox and EXT_BUILD_DEPS containing files from building this same target for other (host, other target) configuration#321
Merged
irengrig merged 1 commit intobazel-contrib:masterfrom Sep 26, 2019
Conversation
…re created in the same execution root with the same names. Apparently, it is not the problem for build outputs, but deps directory that is created by script. What is even more problematic is that this directory can be accessed while building this target in parallel for different configurations. So even if we clean it before using, we might break the build of the parallel target. Solution: create temp directory to be used as deps directory. (Additionally, this demonstrates the benefits of sandboxed execution.)
jin
approved these changes
Sep 26, 2019
Collaborator
jin
left a comment
There was a problem hiding this comment.
LGTM and great catch, thanks for the clear explanation in the PR description.
Contributor
Author
|
Thank you for the quick turnaround! |
lizan
pushed a commit
to envoyproxy/envoy
that referenced
this pull request
Sep 26, 2019
Update rules_foreign_cc to include bazel-contrib/rules_foreign_cc#321 This allows curl to be built with Envoy's libraries for dependencies (c-ares, zlib, ssl) without sandboxing. Testing: OSS-Fuzz builds pointed to this branch Signed-off-by: Asra Ali <asraa@google.com>
danzh2010
pushed a commit
to danzh2010/envoy
that referenced
this pull request
Oct 4, 2019
Update rules_foreign_cc to include bazel-contrib/rules_foreign_cc#321 This allows curl to be built with Envoy's libraries for dependencies (c-ares, zlib, ssl) without sandboxing. Testing: OSS-Fuzz builds pointed to this branch Signed-off-by: Asra Ali <asraa@google.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When executed without sandbox, target- and host- configured targets are created in the same execution root with the same names.
Apparently, it is not the problem for build outputs, but deps directory that is created by script.
What is even more problematic is that this directory can be accessed while building this target in parallel for different configurations. So even if we clean it before using, we might break the build of the parallel target.
Solution: create temp directory to be used as deps directory.
(Additionally, this demonstrates the benefits of sandboxed execution.)
How to execute without sandbox:
bazel build/test --spawn_strategy=standalone
How to reproduce the problem:
For instance, have the results of cmake_external/configure_make be consumed by genrule in tools attribute.
Tools attribute of the genrule is expecting the passed label to exist/ be built for the host configuration.
This way, if you build genrule using your cmake_external target and this cmake_external target with the same command, cmake_external target will be built two times - for host and target.