commit | 24e82426e689853b0d9a04e7b9b6f13e145cf2d6 | [log] [tgz] |
---|---|---|
author | Keith Smiley <keithbsmiley@gmail.com> | Tue Feb 22 06:21:46 2022 -0800 |
committer | Copybara-Service <copybara-worker@google.com> | Tue Feb 22 06:23:32 2022 -0800 |
tree | f0b2249b3de2ac18ae63eae762cacfeef399b9f5 | |
parent | c046f9675d188fcd856119e8f1e9e035727659b1 [diff] |
Fix aggressive params file assumption Most programs that accept params files use the `@file` syntax. For Apple platform builds `@` can be the start of non-params file arguments as well, such as `-rpath @executable_path/Frameworks`. There is a small list of options where this is the case, so this new behavior no longer assumes params files if args start with `@`, they also have to not start with one of the 3 keywords used with this (from `man dyld` on macOS). This should always hold since params files generated by bazel should always start with `bazel-out`, if someone renames the symlinks to one of the keywords, they're on their own. Previously the workaround was to always make sure to pass the `-Wl,-rpath,@executable_path` form of these arguments, but this makes users not have to worry about this. In a few other places we check this by checking if the file exists, which is likely more accurate, but feels excessive and potentially dangerous in this context. Related: https://github.com/bazelbuild/bazel/pull/13148 Fixes: https://github.com/bazelbuild/bazel/issues/14316 Closes #14650. PiperOrigin-RevId: 430195929
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md