ld64 doesn't warn on builds using -install_name if it's a bundle. But, the
current warning is nice to have because install_name only works with dylib.
To prevent an overflow of warnings in build logs and have parity with ld64,
create a --warn-dylib-install-name and --warn-no-dylib-install-name flag
that enables this LLD specific warning.
Details
- Reviewers
gkm thakis - Group Reviewers
Restricted Project - Commits
- rGadfbb5411b0b: [lld-macho] Add warn flags to enable/disable warnings on -install_name
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The flag doesn't have an effect on bundles though. The warning is correct. See D98259 – ld doesn't have this warning at all.
In Chromium, this warning did identify a bunch of places where we passed this flag where it didn't have an effect, so having the warning seems vaguely useful to me.
Maybe we should instead have a flag to disable the warning?
Maybe we should instead have a flag to disable the warning?
The reason for this change is that even though it's a no-op, it's polluting quite bunch of internal build logs which make it hard to uncover what warnings are actually problems and what aren't. As far as the flag to disable the warning, would it better to mirror ld64's behavior and have a flag to enable this check instead? (Alternatively, we could also make the flag to disable the warning a default as well). wdyt?
Yeah, we shouldn't change the error message, since the old one was right :)
I do think we should mirror ld64's (lack of) warnings by default though, since it makes it a better drop-in replacement. I think gating these additional warnings behind something like a --warn-strict flag would be good.
ld64 has a bunch of -no_warn_foo flags to disable specific warnings. That's also the model that clang and lld/COFF use. So maybe we should have a dedicated flag for this warning instead of some umbrella thing?
I'm a bit hesitant about using that scheme because it seems like we could end up with dozens of flags, each for a different warning. But I suppose if the other ports are doing it already then it's nice to follow them
Isn't that _good_ though? Clang has hundreds of warning flags, and I think that's generally appreciated. We should still pick good defaults of course, but likely different projects will want to care about different things.
The patch generally looks good, but I'd probably also add a --warn-dylib-install-name to override the no form, name the config variable to use the positive name ("don't use no double negation") and mention "[--warn-dylib-install-name]" in the warning text so that users know the warning is toggleable (like clang does).
but I'd probably also add a --warn-dylib-install-name to override the no form
Just so I understand here, you're suggesting to rename the current config to --warn-dylib-install-name? It doesn't make sense to have a --warn-no and a --warn because by default, the warning isn't enabled. The reason why I had the name --warn-no-dylib-install-name is to make it clear to readers that install-name can't used with other flags other than -dylib (hence the no...). I do think the name can be a bit confusing with the --warn-no structure, but the name, --warn-dylib-install-name, reads it as if the code should warn if install-name is used with -dylib. Perhaps, --warn-install-name-no-dylib?
No, I mean also adding a --warn-dylib-install-name
It doesn't make sense to have a --warn-no and a --warn because by default, the warning isn't enabled.
Many many flags have both positive and negative forms, in many tools, despite one of them being the default. This is useful because:
a) If you have some hairball build where something passes the non-default flag explicitly for all targets but you want to undo it locally for some target, you can pass the other variant further on
b) It makes it easy to show the default in --help output (just put " (default)" at the end of the help text that has the default. bin/lld-link '/?' has many examples of this.
The reason why I had the name --warn-no-dylib-install-name is to make it clear to readers that install-name can't used with other flags other than -dylib (hence the no...). I do think the name can be a bit confusing with the --warn-no structure, but the name, --warn-dylib-install-name, reads it as if the code should warn if install-name is used with -dylib. Perhaps, --warn-install-name-no-dylib?
Isn't that _good_ though? Clang has hundreds of warning flags, and I think that's generally appreciated. We should still pick good defaults of course, but likely different projects will want to care about different things.
What I had in mind as the alternative was something like --no-warn <warning name>. Sorry, I realize now that I totally neglected to add that context 😅
lld/MachO/Options.td | ||
---|---|---|
76 | I think no-warn makes a lot more sense than warn-no here (btw, LLD-ELF's Options.td has a macro thing to define both the "yes" and "no" versions of a flag. We can consider that as we add more of these. | |
lld/test/MachO/install-name.s | ||
20 | either remove the redirect or check that the output lacks a warning :) |
This lg, thanks. (Either as-is or with s/warn-no/no-warn/)
Please make sure the first line of the commit isn't "[lld-macho] Avoid warning on -install-name if -dylib is not provided" but something updated when committing. ("[lld-macho] Add flag to disable warning on pointless -install_name" or similar)
lld/MachO/Options.td | ||
---|---|---|
76 | --warn-no kind of matches clang's -Wno, which seems vaguely nice to me. But no strong preference. no-warn kind of matches ld64's various -warn_no_ flags, which also seems vaguely nice :) |
I think no-warn makes a lot more sense than warn-no here
(btw, LLD-ELF's Options.td has a macro thing to define both the "yes" and "no" versions of a flag. We can consider that as we add more of these.