Typically linker options are protected with -Xlinker or -Wl, however certain sloppy Makefiles pass -z options directly to the compiler. This patch enables clang to recognize these options (because -z is not used by clang itself). Note the special case of Windows where the call path does not call AddLinkerOptions().
Details
Diff Detail
Event Timeline
I'm against this. I haven't seen enough evidence of use to justify it, other options like -R are certainly a lot more popular...
I haven't seen the -R argument used. Do you have some pointers on this?
We have at least 6 cases in Debian of this usage (http://clang.debian.net/status.php?version=3.4.2&key=UNKNOWN_ARG)
To improve the compatibility with gcc, I think that make sense.
I find some of those build logs very telling. "Unroll loops", "inline functions" and "but don't try too hard". I really would think those should be flagged upstream as "please check the option first".
Sorry, wrong review. -R as alias for -rpath was the most common flag seen in the clang builds on NetBSD. Please keep in mind that GCC will effectively pass *all* unknown flags down to ld, which is why this sort of issue appeared in first place. That's also why I am quite strongly opposed against adding more non-driver flags in the front end.
OK. I understand your argument. Make sense!
What about updating the error message to say something like "Passing linker flags without -Wl, is unsupported" ?
It could simplify the work of porting.
Well, I'm not sure if the additional logic for what really helps that much. Consider just misspelling an option which IMHO is the much more common case.
FWIW I'm in favor. -z is not uncommon in my experience.
That said, a principled way to handle this would be to forward exactly the set of flags that gcc documents:
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options
If you submit a patch to gcc to document -z as a linker option, then we can add it to clang and be done with it. =D
Sadly, I think if gcc documents it we should go ahead and copy that behavior. It's a bit annoying, but the precedent is there and passing it through doesn't harm anything or make it noticeably more difficult to handle.
I disagree with echristo here. We arrived in this situation because GCC never checked. So this should provide at least a warning.
Unfortunately I have to make a couple of changes before committing. I will
get it done first thing tomorrow.
include/clang/Basic/DiagnosticDriverKinds.td | ||
---|---|---|
122 | Maybe "linker argument %0 should be escaped with -Wl, and commas"? Specifically, I think many users won't realize that they need to escape the second space after -z. Alternatively, I would be happy if we removed this diagnostic, but I know Joerg won't. My preferred resolution is, again, that we ask GCC to document -z as a linker option and then we support it without equivocation. | |
include/clang/Driver/Options.td | ||
312 | This can be def z :. For -Z we use Z_Flag and Z_Joined because I think they have different semantics. | |
lib/Driver/Tools.cpp | ||
207 | Why do this check this way instead of .matches(options::OPT_z)? | |
209 | Why not A.claim(); A.render(Args, CmdArgs)? Then you can split this whole clause into it's own 'else if' bucket. | |
7588 | ditto, why not .matches? |
Committed the changes: http://reviews.llvm.org/rL213198. I am now closing this revision.
Maybe "linker argument %0 should be escaped with -Wl, and commas"? Specifically, I think many users won't realize that they need to escape the second space after -z.
Alternatively, I would be happy if we removed this diagnostic, but I know Joerg won't. My preferred resolution is, again, that we ask GCC to document -z as a linker option and then we support it without equivocation.