[BUG] Clang error: unsupported option '-frecord-command-line' for target 'x86_64-w64-windows-gnu'
pmor13 opened this issue · 10 comments
Description
Scenario:
$ cat t1.c
int main(void){}
$ ~/NDK/toolchains/llvm/prebuilt/windows-x86_64/bin/clang t1.c -c
$ ~/NDK/toolchains/llvm/prebuilt/windows-x86_64/bin/clang t1.c -c -frecord-command-line
clang: error: unsupported option '-frecord-command-line' for target 'x86_64-w64-windows-gnu'
# O_o
$ cat NDK/source.properties
Pkg.Desc = Android NDK
Pkg.Revision = 23.1.7779620
How -frecord-command-line is related to target x86_64-w64-windows-gnu?
I thought that -frecord-command-line is target independent.
Is this Clang / LLVM issue or Android NDK issue?
Affected versions
r27
Canary version
No response
Host OS
Windows
Host OS version
Windows 10
Affected ABIs
x86_64
Build system
CMake
Other build system
No response
minSdkVersion
N/A
Device API level
No response
Thanks. I didn't know that this option is target dependent.
The NDK doesn't support non-Android targets.
@DanAlbert Why NDK's default target is non-Android target?
Because that's what Clang does: the target defaults to the target matching the machine clang is running on. There's no sensible default Android target for us to change the default to. Android is 4 (soon 5) distinct ABIs, and about a dozen different OS versions, the cross product of which are all unique targets. You have to choose.
Depending on what you're trying to do, you need to read either https://developer.android.com/ndk/guides/other_build_systems or https://android.googlesource.com/platform/ndk/+/master/docs/BuildSystemMaintainers.md (or maybe just https://developer.android.com/ndk/guides/cmake?)
(it would be nice if we could configure our clangs to just error out without a target, rather than have any default...)
@pirama-arumuga-nainar in case that's feasible. I doubt it's an available configuration option, but maybe upstream would be amenable to changing that.
yeah, i was trying to think whether there's anyone else who's "all cross-, all the time", but couldn't. maybe embedded toolchains? (even if no-one else is interested, it wouldn't be the only if (android) in the driver though, and presumably just one line to error out?)
This may not be worth the effort, IMO. Doing this will fail clang tests that don't specify a triple (for e.g. tests that just check warnings) .
Yeah, +1. You have to be off the beaten path to run into this anyway.