which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
9.5.0.56709
what are you trying to achieve
run sonarqube(fails before sonarqube scanner execution)
Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
Hello,
I am using the sonarqube enterprise edition. We recently switched our compiler for the build, from armr5-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 8.2.0 to armr5-xilinx-eabi-gcc.exe (GCC) 11.2.0. Based on the sonarqube documentation, it supports the GCC compiler which is our new compiler. But somehow I get the following issue:
java.lang.IllegalStateException: The “build-wrapper-dump.json” file was found empty. Please make sure that:
you are using the latest version of the build-wrapper and the CFamily analyzer
your compiler is supported
you are wrapping your build correctly
you are wrapping a full/clean build
If someone needs full debug log file then I can send it over along with the build-wrapper-dump.json.
Yes, it was working with the old compiler - armr5-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 8.2.0 . Do you want to take a look at full debug file(generate using -x command) ?
I checked the changelog and there have been some fixes in the build wrapper since 6.34, which is the one you have, that may improve the situation. Could you update to 9.9 and give it another try?
I tried to download the build wrapper as shown in the screenshot but it keeps download 6.34 version. Is it because I am using sonarqube version 9.5 which is old. Should I upgrade the sonarqube first then download the build wrapper?
I just upgraded my sonarqube to 9.9.0.65466. But when I download the buildwrapper using this method " * Download Build Wrapper for Linux from {SonarQube URL}/static/cpp/build-wrapper-linux-x86.zip", it keeps downloading the older version 6.34.
The below screenshot shows how our build pipeline access the build wrapper. Basically, it gets downloaded every time the pipeline is kicked in, and, then, it gets unzipped.
Sonarqube is properly updated. The CFamily analyzer version is the latest (6.41 we can see in the json and sonar-scanner logs).
There should be a build-wrapper.log stored next to build-wrapper-dump.json. They are both created and closed together, so if the json is there, and properly formed, the log should be. Can you double check that .log file is preserved on your CI?
Without that log is going to be difficult to find out what is happening. We need to know what process executions the build wrapper is seeing.
Sorry, previously, the Jenkins was ignoring and not copying the build-wrapper.log files to the correct output folder. Now, I have the build-wrapper.log files. There two files attached to the zip folder below and they are generated separately for two different types of builds, meaning using two different sets of source files. build-wrapper-logs.zip (904.2 KB)
From what I can see, armr5-none-eabi-gcc is not a binary, but a bash script that calls arm-xilinx-eabi-gcc.real. This explains why the build wrapper does not capture the compiler: the first executable is bash and the second end with an unexpected .real
I was able to run the sonarqube successfully with the help of CMAKE_EXPORT_COMPILE_COMMANDS. I really appreciate for your support.
I checked the compiler and it’s a binary executable not a bash script. Also, added the compiler to this discussion if you want to take a look at it. Maybe somehow this compiler is not supported by sonarqube?
armr5-none-eabi-gcc.exe is a Windows executable indeed, but the logs you sent are from a Linux machine. And this is what hints that it is a wrapper of the actual compiler:
Thu Feb 16 16:39:22 2023: executable: </bin/bash>
Thu Feb 16 16:39:22 2023: argv[0]: </bin/bash>
Thu Feb 16 16:39:22 2023: argv[1]: </tools/Xilinx/SDK/2019.1/gnu/armr5/lin/gcc-arm-none-eabi/bin/../x86_64-oesdk-linux/usr/bin/arm-xilinx-eabi/arm-xilinx-eabi-gcc>
Is there any update on this ticket [CPP-4115] - Jira ? I am facing similar issue moving from gcc 8 to gcc 11. Where a bash script calls the executable ending with “.bin” .
