Closed kmeinhar closed 8 months ago
I'm not sure how this can be fixed -- these clang-based code analysis tools are not compatible with the gcc command line generated in this configuration. I hacked up a change to disable the -fno-printf-return-value
flag which only uncovered a larger issue that the --specs=picolibc.specs
option, which is responsible for setting the correct include path to locate the picolibc headers instead of the newlib headers, was not handled leading to numerous failures.
I didn't see anything in the Zephyr tree which appears to try and paper over the difference between the gcc toolchain and the clang analysis tools? Is this really the first instance where the incompatibilities in command lines has popped up?
cc @pdgendt
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
I suppose we experience the same or similar issue. I am trying to establish CodeChecker in our CI/CD pipeline (alas for another target) and encountered this and a similar problem (flag "-fno-freestanding" is also not recognized by clang). Unfortunately switching lo LLVM as toolchain does not work as the compilation fails for various reasons.
@matthiasbreier
Probably not a proper solution, but I use clangd
as an LSP server with the following config:
# .config/clangd/config.yaml
CompileFlags:
Add: -Wno-unknown-warning-option
Remove: [-m*, -f*]
This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.
1 year later, this is fixed in CodeChecker v6.24.1
Describe the bug With the step to set PicoLibC as default LibC the SCA
CodeChecker
fails for targetefr32bg22_brd4184a
.clang-tidy
fails with errorerror: unknown argument: '-fno-printf-return-value' [clang-diagnostic-error]
. This flag is not supported by Clang and is removed when compiling with Clang: https://github.com/zephyrproject-rtos/zephyr/blob/main/cmake/compiler/clang/compiler_flags.cmake#L11CodeChecker
startsclang-tidy
with options in${CMAKE_BINARY_DIR}/compile_commands.json
. It includes the GCC specific flag-fno-printf-return-value
.To Reproduce
CodeChecker
andclang-tidy
succeed with:west build -b efr32bg22_brd4184a -d build_hello_world zephyr/samples/hello_world -p -- -DZEPHYR_SCA_VARIANT=codechecker -DCONFIG_MINIMAL_LIBC=y
CodeChecker
andclang-tidy
fail with:west build -b efr32bg22_brd4184a -d build_hello_world zephyr/samples/hello_world -p -- -DZEPHYR_SCA_VARIANT=codechecker -DCONFIG_PICOLIBC=y
Expected behavior
clang-tidy
is called without flag-fno-printf-return-value
.Logs and console output
Additional context
Related to #54345
clang-tidy
has the flag--extra-arg=<string>
. But as far as I can tell this does not make it possible to remove compiler flags imported fromcompile_commands.json
.