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

**URL:** <https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204>\
**Category:** SonarQube Server / Community Build\
**Tags:** sonarqube\
**Created:** [July 1, 2024, 8:33pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204 "2024-07-01T20:33:37Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jeff](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/jeff/32/57978_2.png) [@Jeff](https://community.sonarsource.com/u/Jeff)\
**Post date:** [July 1, 2024, 8:33pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/1 "2024-07-01T20:33:37Z")

</div>

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](https://community.sonarsource.com/uploads/short-url/1cDEnrJuOC6bofBpKy13AtgyRoC.json) (252.0 KB)  
[sonar-scanner.log](https://community.sonarsource.com/uploads/short-url/p6sDdzz9Q3ZpOMzXeqC3iBgwEsi.log) (471.9 KB)

---

<div class="post-metadata">

**Author:** ![aalvarez](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/aalvarez/32/39649_2.png) [@aalvarez](https://community.sonarsource.com/u/aalvarez)\
**Post date:** [July 4, 2024, 11:48am UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/4 "2024-07-04T11:48:45Z")

</div>

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`.

---

<div class="post-metadata">

**Author:** ![Jeff](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/jeff/32/57978_2.png) [@Jeff](https://community.sonarsource.com/u/Jeff)\
**Post date:** [July 4, 2024, 9:45pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/6 "2024-07-04T21:45:26Z")

</div>

Thanks - here it is  
[build-wrapper-log.zip](https://community.sonarsource.com/uploads/short-url/vmoKlilP1NbpdZOvfLznPl42PEj.zip) (8.7 MB)

---

<div class="post-metadata">

**Author:** ![aalvarez](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/aalvarez/32/39649_2.png) [@aalvarez](https://community.sonarsource.com/u/aalvarez)\
**Post date:** [July 5, 2024, 7:28am UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/7 "2024-07-05T07:28:46Z")

</div>

Thanks!

From those logs, it looks to me like you are hitting [[CPP-4115] - Jira](https://sonarsource.atlassian.net/browse/CPP-4115) “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?

---

<div class="post-metadata">

**Author:** ![Jeff](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/jeff/32/57978_2.png) [@Jeff](https://community.sonarsource.com/u/Jeff)\
**Post date:** [July 8, 2024, 12:25pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/8 "2024-07-08T12:25:29Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![aalvarez](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/aalvarez/32/39649_2.png) [@aalvarez](https://community.sonarsource.com/u/aalvarez)\
**Post date:** [July 8, 2024, 3:35pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/9 "2024-07-08T15:35:23Z")

</div>

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](https://community.sonarsource.com/uploads/short-url/icScXASGkOLAJypyVWcUsFv1Gia.zip) (563.7 KB)

Please, let me know if this helps.

---

<div class="post-metadata">

**Author:** ![Jeff](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/jeff/32/57978_2.png) [@Jeff](https://community.sonarsource.com/u/Jeff)\
**Post date:** [July 9, 2024, 12:45am UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/10 "2024-07-09T00:45:24Z")

</div>

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](https://community.sonarsource.com/uploads/short-url/9UdB7SrFlHNrK2MszqTKdnNQPBR.zip) (41.2 KB)  
[build-wrapper-log.zip](https://community.sonarsource.com/uploads/short-url/id9sp0lt4f5bc8Oar3l6PIY60IO.zip) (10.2 MB)  
[build-wrapper-dump-json.zip](https://community.sonarsource.com/uploads/short-url/lAis7TJtA0SXLEwhMQQMZsuPZ86.zip) (117.9 KB)

---

<div class="post-metadata">

**Author:** ![aalvarez](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/aalvarez/32/39649_2.png) [@aalvarez](https://community.sonarsource.com/u/aalvarez)\
**Post date:** [July 9, 2024, 2:14pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/11 "2024-07-09T14:14:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![aalvarez](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/aalvarez/32/39649_2.png) [@aalvarez](https://community.sonarsource.com/u/aalvarez)\
**Post date:** [July 9, 2024, 2:55pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/12 "2024-07-09T14:55:30Z")

</div>

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](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](https://clang.llvm.org/docs/JSONCompilationDatabase.html), you could use that option instead.

---

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [May 20, 2025, 3:03pm UTC](https://community.sonarsource.com/t/c-c-objective-c-files-were-analyzed-for-1-of-3-projects/118204/15 "2025-05-20T15:03:19Z")

</div>

Hey @Jeff,

If you didn’t see – last year we introduced support in SonarQube Server for a feature called C/C++ AutoConfig! Removing the question of supported compiler altogether.

> [@C and C++ AutoConfig for SonarQube](https://community.sonarsource.com/t/c-and-c-autoconfig-for-sonarqube/117344):
>
> We have big news for our dear C and C++ SonarQube users. Configuring the analysis requires some skills; at times, it can get technical and tedious, with a few known caveats. We unleashed the talent of our mighty engineers, and they made our C and C++ analyzer smart enough to configure itself. Hence the name AutoConfig. As a result: No need to worry about compiler support No need to worry about build-wrapper or compilation database No need to know anything about the project to configure, nor C…

This is available in SonarQube Server _v10.6+_, although you should really target at least _v2025.1_.
