osx_cc_wrapper: Only expand existing response files #13148
Closed
Conversation
This file contains 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
Not all arguments starting with `@` represent response files, e.g. `-install_name @rpath/...` or `-Xlinker -rpath -Xlinker @loader_path/...`. With this change `osx_cc_wrapper` will only interpret arguments starting with `@` as response files if the corresponding file exists and is readable. This is analogous to the behavior defined in `wrapped_clang.cc`. See bazelbuild#13044 (comment) for discussion.
keith
reviewed
Mar 3, 2021
Co-authored-by: Keith Smiley <[email protected]>
keith
approved these changes
Mar 3, 2021
cocreature
approved these changes
Mar 3, 2021
|
@trybka mind reviewing this one? |
keith
added a commit
to keith/bazel
that referenced
this pull request
Jan 26, 2022
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: bazelbuild#13148 Fixes: bazelbuild#14316
bazel-io
pushed a commit
that referenced
this pull request
Feb 22, 2022
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: #13148 Fixes: #14316 Closes #14650. PiperOrigin-RevId: 430195929
brentleyjones
pushed a commit
to brentleyjones/bazel
that referenced
this pull request
Mar 2, 2022
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: bazelbuild#13148 Fixes: bazelbuild#14316 Closes bazelbuild#14650. PiperOrigin-RevId: 430195929 (cherry picked from commit 24e8242)
Wyverald
pushed a commit
that referenced
this pull request
Mar 2, 2022
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: #13148 Fixes: #14316 Closes #14650. PiperOrigin-RevId: 430195929 (cherry picked from commit 24e8242) Co-authored-by: Keith Smiley <[email protected]>
|
@trybka can you help us land this? |
|
On it |
|
It's running through CI now. Given that it is Friday afternoon here, I don't expect this to land before Monday. |
brentleyjones
pushed a commit
to brentleyjones/bazel
that referenced
this pull request
Mar 21, 2022
Closes bazelbuild#13044 Applies the changes suggested in bazelbuild#13044 (comment) Not all arguments starting with `@` represent response files, e.g. `-install_name @rpath/...` or `-Xlinker -rpath -Xlinker @loader_path/...` do not refer to response files and attempting to read them as such will fail the build. Users don't always have control over these arguments, meaning transforming them to `-Wl,-install_name,@rpath/...` or `-Wl,-rpath,@loader_path/...` is not always an option. E.g. as described in bazelbuild#13044 (comment) where these flags are emitted by the Haskell compiler GHC (see bazelbuild#13044 (comment) for their reasoning). With this change `osx_cc_wrapper` will only interpret arguments starting with `@` as response files if the corresponding file exists and is readable. This is analogous to the behavior defined in `wrapped_clang.cc`. See bazelbuild#13044 (comment) for discussion. Closes bazelbuild#13148. PiperOrigin-RevId: 436207868 (cherry picked from commit efb2b80)
Wyverald
pushed a commit
that referenced
this pull request
Mar 21, 2022
Closes #13044 Applies the changes suggested in #13044 (comment) Not all arguments starting with `@` represent response files, e.g. `-install_name @rpath/...` or `-Xlinker -rpath -Xlinker @loader_path/...` do not refer to response files and attempting to read them as such will fail the build. Users don't always have control over these arguments, meaning transforming them to `-Wl,-install_name,@rpath/...` or `-Wl,-rpath,@loader_path/...` is not always an option. E.g. as described in #13044 (comment) where these flags are emitted by the Haskell compiler GHC (see #13044 (comment) for their reasoning). With this change `osx_cc_wrapper` will only interpret arguments starting with `@` as response files if the corresponding file exists and is readable. This is analogous to the behavior defined in `wrapped_clang.cc`. See #13044 (comment) for discussion. Closes #13148. PiperOrigin-RevId: 436207868 (cherry picked from commit efb2b80) Co-authored-by: Andreas Herrmann <[email protected]>
This was referenced Oct 29, 2024
fmeum
pushed a commit
to bazel-contrib/toolchains_llvm
that referenced
this pull request
Nov 1, 2024
Otherwise the parameter is more than likely a prefix of an `@rpath` so it is probably better off leaving as it is. This simply ports the following fix: bazelbuild/bazel#13148 Resolves #408
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Closes #13044
Applies the changes suggested in #13044 (comment)
Not all arguments starting with
@represent response files, e.g.-install_name @rpath/...or-Xlinker -rpath -Xlinker @loader_path/...do not refer to response files and attempting to read them as such will fail the build.Users don't always have control over these arguments, meaning transforming them to
-Wl,-install_name,@rpath/...or-Wl,-rpath,@loader_path/...is not always an option. E.g. as described in #13044 (comment) where these flags are emitted by the Haskell compiler GHC (see #13044 (comment) for their reasoning).With this change
osx_cc_wrapperwill only interpret arguments starting with@as response files if the corresponding file exists and is readable. This is analogous to the behavior defined inwrapped_clang.cc. See #13044 (comment) for discussion.