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

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

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)

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 <keithbsmiley@gmail.com>

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)

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 <andreash87@gmx.ch>

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