extractArgumentsForDynamicLinkParamFile causes arguments that start with @rpath to be interpreted as a param file
#14316
Labels
P3
We're not considering working on this, but happy to review a PR. (No assignee)
platform: apple
team-Rules-CPP
Issues for C++ rules
type: feature request
Comments
|
FWIW this was a bit of an intentional tradeoff when we added params files support. In the shell scripts we check if the file exists, and assume that if it doesn't it's an intentional arg otherwise, so we could do the same here to fix it probably. |
|
So is this working as intended? |
|
We should fix anywhere we can easily, but most of the time the recommendation is to change whoever is passing the flag to use the |
keith
added a commit
to keith/bazel
that referenced
this issue
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
oquenchil
added
P3
|
@bazel-io fork 5.1 |
brentleyjones
pushed a commit
to brentleyjones/bazel
that referenced
this issue
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 issue
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 <keithbsmiley@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the problem / feature request:
While updating rules_apple we couldn't use
@rpatharguments as it would result in a build failure. Instead we had to pass the arguments in a different way:https://github.com/bazelbuild/rules_apple/pull/1207/files#diff-d84498974951b9a579baeeaf19d52ffb0a42a15b520c4359dac92448e2b806ceR670
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
This code needs to be updated to support arguments that start with
@rpath:bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/LinkCommandLine.java
Line 295 in 1c3a245
What operating system are you running Bazel on?
macOS 11.6.1
What's the output of
bazel info release?5.0.0rc2
The text was updated successfully, but these errors were encountered: