Problem using C build-wrapper on gcc variants

Hello. I have recently deployed Sonarqube at my company and we have succesfully managed to get a c project analysed that employs the arm-eabi-gcc compiler.

We are now trying get other C projects for another platform analysed in the same manner but are running into an issue whereby the C build-wrapper does not seem to recognize our compiler despite it also being a gcc compiler. In this case the code is compiled using the Microblaze gcc compiler which has a perhaps unusual executable name “mb-gcc” In this instance where the analysis fails we are compiling the project through the build-wrapper and the compilation completes succesfully. During the sonarscanner/upload script we are getting the following messages

INFO: PCH: unique=0 use=0 (forceInclude=0,throughHeader=0,firstInclude=0) out of 0 (forceInclude=0,thr                                                              oughHeader=0)
INFO: SE: 0 out of 0
INFO: Z3 refutation rate: 0 out of 0
INFO: Subprocess(es) done in 15ms
INFO: 0 compilation units analyzed
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 5.991s
INFO: Final Memory: 24M/94M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found empty. Please make sure that:

I can confirm that the build-wrapper-dump.json is “empty” it contains only a version tag and an empty “captures” section

Looking at the logs it seems the build-wrapper is “skipping” the process that executes the compiler. In the logs below I have redacted filepaths and names, but you can see that process 23908 executes our compiler “mb-gcc” and then “skips” it seemingly not recognizing it as valid compiler

Tue Jun 07 13:40:25 2022: parent pid: 23904
Tue Jun 07 13:40:25 2022: working directory: </home/genericUser/Documents/Sandbox/FPGA/workingdir>
Tue Jun 07 13:40:25 2022: executable: </usr/bin/dash>
Tue Jun 07 13:40:25 2022: argv[0]: </bin/sh>
Tue Jun 07 13:40:25 2022: argv[1]: <-c>
Tue Jun 07 13:40:25 2022: argv[2]: <mb-gcc -Wall -O0 -g3 -c -fmessage-length=0 -MT"src/generic_source_name.o" -I/home/path/to/includes>
Tue Jun 07 13:40:25 2022: skipping process with pid: 23907
Tue Jun 07 13:40:25 2022: process created with pid: 23908
Tue Jun 07 13:40:25 2022: parent pid: 23907
Tue Jun 07 13:40:25 2022: working directory: </home/genericUser/FPGA/workingdir>
Tue Jun 07 13:40:25 2022: executable: </usr/bin/bash>
Tue Jun 07 13:40:25 2022: argv[0]: </bin/bash>
Tue Jun 07 13:40:25 2022: argv[1]: </tools/path-to-toolchain/mb-gcc>
Tue Jun 07 13:40:25 2022: argv[2]: <-Wall>
Tue Jun 07 13:40:25 2022: argv[3]: <-O0>
Tue Jun 07 13:40:25 2022: argv[4]: <-g3>
Tue Jun 07 13:40:25 2022: argv[5]: <-c>
....
other compiler options
....
Tue Jun 07 13:40:25 2022: argv[25]: <src/generic_source_name.o>
Tue Jun 07 13:40:25 2022: argv[26]: <../src/generic_source_name.c>
Tue Jun 07 13:40:25 2022: skipping process with pid: 23908
Tue Jun 07 13:40:25 2022: process created with pid: 23909
Tue Jun 07 13:40:25 2022: parent pid: 23908
Tue Jun 07 13:40:25 2022: working directory: </home/genericUser/Documents/Sandbox/FPGA/workingdir>
Tue Jun 07 13:40:25 2022: executable: </usr/bin/dirname>
Tue Jun 07 13:40:25 2022: argv[0]: <dirname>
Tue Jun 07 13:40:25 2022: argv[1]: <tools/path-to-toolchain/mb-gcc>
Tue Jun 07 13:40:25 2022: skipping process with pid: 23909
Tue Jun 07 13:40:25 2022: process created with pid: 23910
Tue Jun 07 13:40:25 2022: parent pid: 23908
Tue Jun 07 13:40:25 2022: working directory: </home/genericUser/FPGA/workingdir>
Tue Jun 07 13:40:25 2022: executable: </usr/bin/dirname>
Tue Jun 07 13:40:25 2022: argv[0]: <dirname>
Tue Jun 07 13:40:25 2022: argv[1]: <tools/path-to-toolchain/mb-gcc>
Tue Jun 07 13:40:25 2022: skipping process with pid: 23910
Tue Jun 07 13:40:25 2022: process created with pid: 23911
Tue Jun 07 13:40:25 2022: parent pid: 23908

Is there a way to force the build-wrapper to recognize mb-gcc as a gcc compiler?

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
  • what are you trying to achieve
  • what have you tried so far to achieve this

Hi @vmass,

Can you provide an answer to this questions:

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

Mainly SonarQube and build-wrapper versions.

We should be recognize mb-gcc so the problem isn’t in the name.

The compiler process is the one that has as an executable mb-gcc the one you showed doesn’t; it is an argument. Do you have that in the build-wrapper log? if you cannot find the compilation process in the build-wrapper log:

  • Is your compiler statically linked?
  • Is the compilation executed on a daemon process which explains why it is not in the log.
  • How are you calling the compiler?

Thanks,

Hi Abbas

We are using Sonarqube V9.2.4.50792, the build-wrapper is the one that is available for download from our sonarqube instance (the version for linux)

To answer your other questions. The compiler is called via a makefile/make. We call “make clean all” from a simple shell script “buildscript.sh”. I do not think a daemon is involved. Our target is an embedded system so Im pretty sure we are using static linkage. Everything goes into the final executable.

cd Debug/
make clean
make

Another shell script calls the buildwrapper and we feed the buildscript.sh to the buildwrapper

source /tools/Xilinx/Vivado/2021.1/settings64.sh
build-wrapper-linux-x86-64 --out-dir temp  ./buildscript.sh

@vmass,

I’m asking if your compiler is statically linked, not your project.

Did you find the actual mb-gcc execution in the log file? If not can you share the build-wrapper.log file? I can send you a private message if you prefer to share it privately

Thanks,

Looking more carefully at the logs I do not see the mb-gcc ever being listed as the “executable”. It appears to always be one of the arguments to a call to /usr/bin/bash, and following that, the logs show repeated calls to dirname, realpath, basename etc. I can send you a more complete log (How can I do this privately)

As to your other question. How could I determine whether the compiler is statically linked or not. A quick google search only turns up topics related to linkage of a compiled project and not the compiler itself

hi @vmass,

Sorry for the late reply. I totally missed your question.

Like any other executable:
file -L tools/path-to-toolchain/mb-gcc

or ldd tools/path-to-toolchain/mb-gcc to see the list of dynamic libraries needed for your compiler.

I will send you a private message where you can share more logs.

Thanks,

ldd pathto/mb-gcc
returns
“not a dynamic executable”

I guess this means it’s not dynamically linked. Can you explain why this is important?

@vmass,

build-wrapper uses a dynamic library loaded with LD_PRELOAD in order to observe compiler calls. That means that cannot observe statically linked binaries. to work around this you can

  • Use a dynamically linked version of your compiler.
  • have a small bash wrapper with the same name mb-gcc which simply calls the real mb-gcc, this should allow build-wrapper to observe the bash call and fetch the configuration
  • If both options are feasible and you can generate a compilation database for your project, you can use it instead of build-wrapper: SonarQube

Thanks,

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.