C/C++/Objective-C files were analyzed for 1 of 3 projects

SonarQube Server / Community Build
1

SonarScanner 5.0.1.3006 running native in Ubuntu / SonarQube server 9.9.5.90363

We are doing C compilation for STM32, Xilinx 7000, and Xilinix Ultrascale, all GCC based toolchains. Sonar scanner works great for the STM32 and 7000 project, but not for the Ultrascale. It’s seems like the toolchain can’t be found (at least it’s not in the logs). The build process for all three is very similar, similar paths, etc. Attached logs, thanks for any clues!
build-wrapper-dump.json (252.0 KB)
sonar-scanner.log (471.9 KB)

4

Hello @Jeff,

Sorry for the delay in answering.

There should be a file named build-wrapper.log next to the json. Could you share it as well? There we should be able to see the compilations that were not written into the json.

6

Thanks - here it is
build-wrapper-log.zip (8.7 MB)

7

Thanks!

From those logs, it looks to me like you are hitting [CPP-4115] - Jira “Support toolchains that wrap the compiler within a script”

This should have been fixed with the analyzer shipped with SonarQube 10.5.
Would it be possible to try this version?

8

Thanks Alejandro - here’s the reply I got from out IT team:
We don’t have a server running that version of Sonarqube, we’re running the latest LTS version which is 9.9.5.
Is there another possible solution?

9

Hi,

Maybe using a more recent version of build-wrapper would unlock you, even if you use the 9.9 LTS. Here you have the build wrapper from SQ 10.5:

build-wrapper-linux-x86.zip (563.7 KB)

Please, let me know if this helps.

10

Ok the error message has changed to: “The compiler probe ‘stdout’ is expected to contain at least one ‘#define’ directive”. Attaching log files, thanks again!
sonar-scanner.zip (41.2 KB)
build-wrapper-log.zip (10.2 MB)
build-wrapper-dump-json.zip (117.9 KB)

11

Thanks for the logs.

It seems we have trouble capturing the compiler invocation. I can reproduce locally using the same toolchain. From what I see, the compiler is invoked indirectly using ld-linux-x86-64.so.2, which we capture fine. But we wrongly capture the first argument of the executable, which should be ld-linux-x86-64.so.2 . However, we have the compiler as argv[0], which breaks the compiler probe on a later stage. In fact, we are also missing ld’s parameter --library-path.

I am trying to figure out why we miss the flags passed to the linker

12

I think I understand what is going on. However, it is far from a trivial fix. Here is the ticket
https://sonarsource.atlassian.net/browse/CPP-5462

Basically, the compiler is called via the dynamic linker, which, in addition to loading the shared libraries and the like, will also set up argc and argv so the loaded binary “sees” itself and not the loader.

Hence, we get the dynamic loader as executable but with the compiler arguments, which is why the probing fails.

As a workaround, if your build system supports generating compilation databases, you could use that option instead.