Add optional GCC static analyzer support to CMake and Conan builds by moelksasbyahmed · Pull Request #817 · apache/celix

moelksasbyahmed · 2026-01-27T13:02:11Z

This PR adds optional support for GCC’s static analyzer (-fanalyzer) to the Celix build system.

What’s included

Introduces a new CMake option:
ENABLE_GCC_ANALYZER (OFF by default)

When enabled and using GCC, -fanalyzer is added to:

CMAKE_C_FLAGS

CMAKE_CXX_FLAGS

Extends conanfile.py with a corresponding option (enable_gcc_analyzer) so the analyzer can also be enabled in Conan-based builds.

What’s not included

No analyzer warnings are fixed in this PR.
The analyzer is not enabled in CI.
No behavior or runtime changes.

Motivation

GCC’s static analyzer has been improving significantly in recent releases and can help detect issues such as possible null dereferences and resource leaks.
This PR lays the groundwork for experimenting with the analyzer locally and for potential future CI integration.

Analyzer warnings can be addressed incrementally in follow-up PRs once there is agreement on scope and expectations.

pnoltes

Thanks for the PR :)

Some small remarks and a question.

Is it also possible to enable one of the CI builds (ubuntu, gcc) with the analyzer option?
And then suppress the warnings we have not yet fixed (-Wno-analyzer-double-fclose, etc).

This can also help in follow up task (enable the analyzer warnings, flag per flag).

conanfile.py

pnoltes · 2026-01-27T20:01:06Z

cmake/celix_project/CelixProject.cmake

+        set(CMAKE_C_FLAGS "-fanalyzer ${CMAKE_C_FLAGS}")  
+        set(CMAKE_CXX_FLAGS "-fanalyzer ${CMAKE_CXX_FLAGS}")  
+    else()  
+        message(WARNING "ENABLE_GCC_ANALYZER is only supported with GCC compiler 10.0.0 OR higher.")  


Suggested change

message(WARNING "ENABLE_GCC_ANALYZER is only supported with GCC compiler 10.0.0 OR higher.")

message(WARNING "ENABLE_GCC_ANALYZER is only supported with GCC")

I would not mention the version, because that is not what is tested in the if.

moelksasbyahmed · 2026-01-28T01:02:30Z

Hi @pnoltes, thanks for the review. i can surely enable the analyzer in the Ubuntu GCC CI build and suppress the warnings, but i have a question. By reviewing the docs of -fanalyzer see Options That Control Static Analysis, how do you suggest adding these flags to the build in efficient way like to make it easy to suppress every flag one after the other ? my approach is 07c3f50 if there is a better and more efficient approach i will be happy to learn and apply

conanfile.py

pnoltes · 2026-02-03T17:46:20Z

lag one after the other ?

I think this approach is good. I like to usage of 'add_compile_options' and the split-up of suppressing a warning per line.

moelksasbyahmed · 2026-02-04T08:59:56Z

the CI build Ubuntu / linux-build-apt debug or RelWithDepInfo is failing due to error code 143. I'm really wondering why is that i think it due to analyzer taking alot of time while building in the ci should i remove it from the CI build ? or if im wrong what could be the mistake i did in the CI workflow that caused this ?

pnoltes · 2026-02-04T19:31:21Z

the CI build Ubuntu / linux-build-apt debug or RelWithDepInfo is failing due to error code 143. I'm really wondering why is that i think it due to analyzer taking alot of time while building in the ci should i remove it from the CI build ? or if im wrong what could be the mistake i did in the CI workflow that caused this ?

I am not sure, I was also looking at this. I should not be a time limit, this is set on 120 minutes.

Seeing actions/runner-images#6680 (comment) I expect it is maybe due to reaching a the memory resource limit. Could you try using ninja -j8 or ninja -j4 instead of ninja?

moelksasbyahmed · 2026-02-04T22:12:44Z

hi @pnoltes i tried ninja -j2 and RelWithDepInfo and it worked but debug didnt should i make ninja -j1 but it will make the build so slow or should i just remove analyzer from the CI work flow

pnoltes · 2026-02-05T07:02:15Z

hi @pnoltes i tried ninja -j2 and RelWithDepInfo and it worked but debug didnt should i make ninja -j1 but it will make the build so slow or should i just remove analyzer from the CI work flow

I see that the debug one ran over the configured 120minute limit.

I think we can test a bit more and then discuss whether we want gcc analyse in our builds and if so how. Could you provide an update with -j4 to check if that helps (a bit faster, but hopefully not parallel enough to eat too much memory)?

I had a quick look and there are also ASF infra hosted runners (https://cwiki.apache.org/confluence/display/INFRA/ASF+Infra+provided+self-hosted+runners), so this could be another route. Not yet sure if this is (memory wise) a step up from the GitHub hosted runners.

Maybe already good to minimise the usage of the gcc static analyzer to a single build? I think, not sure, that there is no benefit to run the gcc static analyzer in the debug build (compared to the RelWithDebInfo build) and seeing the latest build I expect the analyzer performs better with a RelWithDebInfo build.

PengZheng · 2026-02-05T12:33:50Z

Maybe already good to minimise the usage of the gcc static analyzer to a single build? I think, not sure, that there is no benefit to run the gcc static analyzer in the debug build (compared to the RelWithDebInfo build) and seeing the latest build I expect the analyzer performs better with a RelWithDebInfo build.

+1

Moreover, it does not make sense to enable analyzer for tests.
Note that half of our code base is for testing code and compilation (and static analysis) of C++ code is very slow.

WDYT @pnoltes

added the -wno for the shift registers Fix: suppress static analyzer warning in tlsf.c added the suppresser for shift count reister added the suppresser for shift count register added -j8 for ninja build testing ninja -j2 testing ninja -j4 static analyzer only on RelWithDebInfo only testing ninja -j8 static analyzer only on RelWithDebInfo only testing ninja static analyzer only on RelWithDebInfo only testing ninja -j8 static analyzer only on RelWithDebInfo only enabling the gcc static analyzer on RelWithDebInfo enabline gcc static analyzer on RelWithDebInfo build only

moelksasbyahmed · 2026-02-05T15:20:40Z

i tried to build with ninja -j4 and it worked and i tried with -j8 and it worked too
i limited the analyzer build to only RelWithDepiInfo build by adding -DENABLE_GCC_ANALYZER=${{matrix.type == 'RelWithDebInfo' && 'ON' || 'OFF'}} to ubutnu.yml i tested the build on actions on my forked github repo and it works

moelksasbyahmed · 2026-02-05T22:43:40Z

well the CI workflow RelWithDebInfo ran at my forked repo fine and in here it failed in web sockets i searched but i couldnt figure out the problem any idea ?

PengZheng · 2026-02-06T03:35:51Z

well the CI workflow RelWithDebInfo ran at my forked repo fine and in here it failed in web sockets i searched but i couldnt figure out the problem any idea ?

HttpInfoTestSuite.http_admin_info_test is coded to use port 45112, which may be used by someone else.
Nothing to worry about.

pnoltes · 2026-02-06T07:34:02Z

Maybe already good to minimise the usage of the gcc static analyzer to a single build? I think, not sure, that there is no benefit to run the gcc static analyzer in the debug build (compared to the RelWithDebInfo build) and seeing the latest build I expect the analyzer performs better with a RelWithDebInfo build.

+1

Moreover, it does not make sense to enable analyzer for tests. Note that half of our code base is for testing code and compilation (and static analysis) of C++ code is very slow.

WDYT @pnoltes

I’m actually in favor of including the test code. While we could create a specific CI pipeline with tests disabled, the goal of enabling the GCC static analyzer is to catch and fix issues as we write new code. Since development happens with tests enabled, the test code should be compatible with the analyzer as well.

In my view, we should either accept a slower build (limiting parallelism to (.i.e.) -j4) or postpone the analyzer's introduction. I personally prefer the slower build. We can look into ASF-hosted runners later to optimize.

Another option is running the analyzer only on PRs, but I’m not a fan of that approach as it loses immediate feedback during development.

pnoltes · 2026-02-06T07:35:27Z

.github/workflows/ubuntu.yml

          -DCMAKE_BUILD_TYPE=${{ matrix.type }}
          -DENABLE_CCACHE=ON
          -DCMAKE_POLICY_VERSION_MINIMUM=3.5
+          -DENABLE_GCC_ANALYZER=${{matrix.type == 'RelWithDebInfo' && 'ON' || 'OFF'}}


👍 , Nice clean way to do this

pnoltes

Looks good. IMO using -j8 for gcc static analyzer and only using it on RelWithDebInfo is for now the correct approach.

moelksasbyahmed · 2026-02-06T11:44:55Z

In my view, we should either accept a slower build (limiting parallelism to (.i.e.) -j4) or postpone the analyzer's introduction. I personally prefer the slower build. We can look into ASF-hosted runners later to optimize.

well i tried to make it slow by enable -j2 and i ran the workflow on my forked repo the debug build reached memory limit and has exit code of 143 check forked repo workflow so i guess the valid options is making the build so slow by making ninja -j1 or making a specific Ci pipeline with test disabled but i agree with you the build should be compatible with test as well so i guess the only valid option is making the build slow by ninja -j1 and it can be optimized later i will search for valid solutions

pnoltes · 2026-02-06T18:17:02Z

In my view, we should either accept a slower build (limiting parallelism to (.i.e.) -j4) or postpone the analyzer's introduction. I personally prefer the slower build. We can look into ASF-hosted runners later to optimize.

well i tried to make it slow by enable -j2 and i ran the workflow on my forked repo the debug build reached memory limit and has exit code of 143 check forked repo workflow so i guess the valid options is making the build so slow by making ninja -j1 or making a specific Ci pipeline with test disabled but i agree with you the build should be compatible with test as well so i guess the only valid option is making the build slow by ninja -j1 and it can be optimized later i will search for valid solutions

Maybe I missing something, but the current build uses gcc static analyzer with RelWithDebInfo and ninja -j8: https://github.com/apache/celix/actions/runs/21716569744/job/62701713167?pr=817#step:6:23

So looks good to me. I want to wait till we have 2 approvals and then merge the PR.

PengZheng

Nice addition! LGTM

pnoltes · 2026-02-07T08:55:16Z

@moelksasbyahmed Thanks for the contribution :)

moelksasbyahmed · 2026-02-07T10:47:10Z

@pnoltes @PengZheng thanks for giving me oppertunity to contributoe to celix and answer my question

moelksasbyahmed added 2 commits January 27, 2026 13:14

adding cmake support for gcc -fanalyzer

c46a284

added support for gcc -fanalyzer for conanfile

0454477

moelksasbyahmed mentioned this pull request Jan 27, 2026

Utilize latest GCC/clang's capability in CI #566

Open

pnoltes requested changes Jan 27, 2026

View reviewed changes

moelksasbyahmed added 3 commits January 28, 2026 01:24

applied the requested changes

666cf19

added -fanalyzer flags to suppress warnings in CMake

07c3f50

added gcc analyzer for the ubuntu build

425b689

modified conanfile.py to enable gcc analyzer using cmake

3ca7128

PengZheng reviewed Jan 31, 2026

View reviewed changes

conanfile.py Outdated Show resolved Hide resolved

moelksasbyahmed force-pushed the master branch 2 times, most recently from 02744ae to 2f9845d Compare February 3, 2026 15:30

moelksasbyahmed force-pushed the master branch from dc4ffc2 to 1fbdb32 Compare February 5, 2026 15:03

pnoltes reviewed Feb 6, 2026

View reviewed changes

pnoltes approved these changes Feb 6, 2026

View reviewed changes

PengZheng approved these changes Feb 7, 2026

View reviewed changes

pnoltes merged commit 78dadfa into apache:master Feb 7, 2026
23 of 24 checks passed

pnoltes linked an issue Feb 10, 2026 that may be closed by this pull request

Utilize latest GCC/clang's capability in CI #566

Open

	message(WARNING "ENABLE_GCC_ANALYZER is only supported with GCC compiler 10.0.0 OR higher.")
	message(WARNING "ENABLE_GCC_ANALYZER is only supported with GCC")

Conversation

moelksasbyahmed commented Jan 27, 2026

This PR adds optional support for GCC’s static analyzer (-fanalyzer) to the Celix build system.

What’s not included

Uh oh!

pnoltes left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pnoltes Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

moelksasbyahmed commented Jan 28, 2026

Uh oh!

Uh oh!

pnoltes commented Feb 3, 2026

Uh oh!

moelksasbyahmed commented Feb 4, 2026

Uh oh!

pnoltes commented Feb 4, 2026

Uh oh!

moelksasbyahmed commented Feb 4, 2026

Uh oh!

pnoltes commented Feb 5, 2026

Uh oh!

PengZheng commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

moelksasbyahmed commented Feb 5, 2026

Uh oh!

moelksasbyahmed commented Feb 5, 2026

Uh oh!

PengZheng commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pnoltes commented Feb 6, 2026

Uh oh!

pnoltes Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

pnoltes left a comment

Choose a reason for hiding this comment

Uh oh!

moelksasbyahmed commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pnoltes commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PengZheng left a comment

Choose a reason for hiding this comment

Uh oh!

pnoltes commented Feb 7, 2026

Uh oh!

Uh oh!

moelksasbyahmed commented Feb 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

PengZheng commented Feb 5, 2026 •

edited

Loading

PengZheng commented Feb 6, 2026 •

edited

Loading

moelksasbyahmed commented Feb 6, 2026 •

edited

Loading

pnoltes commented Feb 6, 2026 •

edited

Loading