Fix Clang detection #4897
Closed
Fix Clang detection #4897
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The previous way that Clang was detected was not working: first the
string is cast to lowercase, and then there's a check for "LLVM"
(uppercase) which of course will never work. This change removes that
useless check and replaces it with a check for the filename (like is
already the case for GCC) so that Clang is detected in at least some
cases.
The reason this is necessary is because I'm trying to add a WebAssembly
target which uses Clang, and which uses wasm-ld for linking. Sadly,
PlatformIO adds `-Wl,--start-group` and `-Wl,--end-group` which aren't
supported by wasm-ld. But they shouldn't have been added anyway: they
were only added because the compiler was (incorrectly) detected as GCC.
Sidenote: the reason Clang is detected as GCC is because `$CC -v` (which
expands to `clang -v`) outputs the following on my system:
clang version 17.0.6 (Fedora 17.0.6-2.fc39)
Target: aarch64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/aarch64-redhat-linux/13
Selected GCC installation: /usr/bin/../lib/gcc/aarch64-redhat-linux/13
Candidate multilib: .;@m64
Selected multilib: .;@m64
This contains the string 'GCC' even though it is Clang. Perhaps the
correct command would be `$CC --version`? It outputs the following
instead:
clang version 17.0.6 (Fedora 17.0.6-2.fc39)
Target: aarch64-redhat-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
There is no 'gcc' string here!
The GCC version of this (`gcc --version) also outputs something more
reasonable:
gcc (GCC) 13.2.1 20240316 (Red Hat 13.2.1-7)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
Thanks for the PR! Please re-test with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The previous way that Clang was detected was not working: first the string is cast to lowercase, and then there's a check for "LLVM" (uppercase) which of course will never work. This change removes that useless check and replaces it with a check for the filename (like is already the case for GCC) so that Clang is detected in at least some cases.
The reason this is necessary is because I'm trying to add a WebAssembly target which uses Clang, and which uses wasm-ld for linking. Sadly, PlatformIO adds
-Wl,--start-groupand-Wl,--end-groupwhich aren't supported by wasm-ld. But they shouldn't have been added anyway: they were only added because the compiler was (incorrectly) detected as GCC.Sidenote: the reason Clang is detected as GCC is because
$CC -v(which expands toclang -v) outputs the following on my system:This contains the string 'GCC' even though it is Clang. Perhaps the correct command would be
$CC --version? It outputs the following instead:There is no 'gcc' string here!
The GCC version of this (
gcc --version) also outputs something more reasonable: