SonarQube failed to analyze C++ project,

SonarQube Server / Community Build
,
1
  • which versions are you using (SonarQube Server / Community Build, Scanner, Plugin, and any relevant extension)
    SonarQube Server * Enterprise Edition v2025.1 (102418)
    SonarScanner 5.0.1.3006
  • how is SonarQube deployed: zip, Docker, Helm
    Docker
  • what are you trying to achieve
    I’m try to analyze C++ code using compilation database
  • what have you tried so far to achieve this
    For my testing I build a simple project code cpp use cmake to generate the Compilation file
    but the scanner failed

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
sonarscanner.log (29.2 KB)

5

Hello @SCHEBBI_ALLIANZ ,

From what I see, /usr/bin/c++ is gcc. It is odd probing it times out.
Can you confirm the following command runs on the same machine than the scanner? Do if before the scanner but after the compilation.

time /usr/bin/c++ -x c++ --std gnu++11 -v -dM -E - < /dev/null

How long does it take to run?

And, while on it, is the build running on hardware, container, VM…? Which OS is it?

6

Hey thanks for your reply

I just run the command here the result
|real|0m 0.01s|
|user|0m 0.00s|
|sys|0m 0.00s|

for the build I run it in the same docker image of the scanner to be sure that we have the same environments

What about this message :
eventual compiler license check over network is not taking too much time
Is there any license check need it?

7

That message is intended for compilers that need a license, which isn’t the case.
Sometimes it triggers in macos when Rosetta is involved, but shouldn’t apply either.

Can you share the docker image you are using, so I can try to reproduce?

8

Unfortunately the image is in private repo I cannot shared but I can share the dockerfile for the scanner if it can help

DockerFile.txt (1.0 KB)

and simple cpp project that we try to scan
— src
------- main.cpp

#include

int main() {
std::cout << “Hello, World!” << std::endl;
return 0;
}

—CMakeLists.txt

cmake_minimum_required(VERSION 3.10)
project(MyProject)

set(CMAKE_CXX_STANDARD 11)

add_executable(main src/main.cpp)

And this is the commad used to build it cpp project
- mkdir build
- cd build
- cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
- make

9

It seems to be Alpine Linux based? We don’t support Alpine Linux because we rely on glibc.

I have also found this old thread with the same issue you are facing, so this confirms it is an issue with musl.

I have linked this conversation to the Jira ticket to helps us record the traction musl has.

For the moment being, I can only suggest using a container based on a distribution that uses glibc.

11

Thanks for your help, I have requested a container based on a distribution that uses glibc, meanwhile I’m trying another solution using AutoConfig to analyze my simpte C++ project with code smells.

But I have an issue this time sonarqube doesn’t detect any of the issues in the code(0 Security, 0 Reliability; 0 Maintainability, 0 Security Hotspots)
sonar_scanner.log (9.7 KB)

Do you have any idea why it doesn’t work correctly?

Regards

12

These logs seem to be the same as the one above, it is using compilation database (plus, the URL is the same, so I imagine discuss has de-duplicated the file)

13

sorry it was the wong file here the correct one
sonar_scanner.log (9.7 KB)

14 
INFO: Java 17.0.12 Alpine (64-bit)

Unfortunately it is still Alpine. Part of the analyzer is native and has the same requirement on glibc.

15

Ok AutoConfig ialso need the glibc
Thanks for help

16

There’s no need to explicitly support musl. Just avoid using non-POSIX features from glibc — I believe it’s being linked accidentally.

Also, Alpine provides a small compatibility layer for glibc, but it’s still not sufficient in this case:

Please reduce the reliance on hardcoded glibc usage. This shouldn’t be a major task.

$ ldd subprocess
/lib64/ld-linux-x86-64.so.2 (0x7f974248e000)
libseam.so => ./libseam.so (0x7f973d3ac000)
libz.so.1 => /usr/lib/libz.so.1 (0x7f973d391000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f974248e000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f974248e000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f974248e000)
librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f974248e000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f974248e000)
ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7f973d38a000)
Error relocating subprocess: strtoll_l: symbol not found
Error relocating subprocess: strtoull_l: symbol not found
Error relocating subprocess: mallinfo: symbol not found
Error relocating subprocess: backtrace: symbol not found
Error relocating subprocess: __register_atfork: symbol not found

17

Hello @Misery ,

Thanks for the detailed report. We had tried gcompat in the past and found the same issues as you: not all symbols we link against are provided by it. However, these dependencies are indirect, so removing them is not an immediately obvious fix.

Nonetheless, I have linked your comment to the relevant ticket to give it more weight:

19

Thanks for info. Ok, if it is hard to change the dependency you could just link glibc statically. This allows to run on non-glibc plattforms, too.