Build fails with CMake 4.0.0 due to compatibility issue in libcorrect

[kerel-fs]

With CMake release 4.0.0, compatibility with CMake < 3.5 has been (soft-)removed. This causes builds to fail due to a compatibility problem in core/libcorrect/CMakeLists.txt.

Error Message

CMake Error at core/libcorrect/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

Steps To Reproduce On a system with CMake 4.0, checkout git repository of SDR++ and run cmake:

$ git clone https://github.com/AlexandreRouma/SDRPlusPlus
$ cd SDRPlusPlus
$ cmake -B build -S .

Software

• CMake version 4.0.0
• Operating System: Manjaro Linux x86_64 (as of April 24, 2025)
• SDR++: Latest commit on main, 2dd8c6ce

Workaround Add argument -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to cmake (only works until the compatibility is hard-removed).

Suggested solutions

Update the cmake_minimum_required version in core/libcorrect/CMakeLists.txt to 3.5 or higher.

Additional Notes This problem has been reported by Arch Linux users building from AUR.

[AlexandreRouma]

Editing the cmakelists of a vendored library is a bad idea. You should report it to https://github.com/quiet/libcorrect but considering they haven't commited anything in 7 years I doubt they'll "fix" it.

Not yet sure how I'll go about it, I'll come back to this once I've decided on a fix/workaround.

[alexey-lysiuk]

Changes to vendored libcorrect were already made, c8bdd2e52be832292643c9db05f599ec9513ed18 and 03f173a3ac1df9408e8b736e3e7697e08d5a03d2. Also, ff23d7e43f6f3024f87ab7161d295135def457d9 without touching CMake though. There is another issue with libcorrect I'm investigating right now. Most likely, it will require some changes as well.

[AlexandreRouma]

Those were all benign changed working around the lack of options to disable certain unwanted features and just getting the thing to compile at all on android.

Changing the cmake_minimum_required line means that cmake may behave differently then the CMakeLists author expected which could result in annoying issues in the future.

So as I said, report to upstream for now. The solution will likely be to completely stop using libcorrect in favor of either something custom or libfec.

[alexey-lysiuk]

Alright, I have reported libcorrect issue. I guess, there is no reason to duplicate it here. Still, the chance to get it fixed there is very slim.

Are you against changing vendored libraries in any form, or it's just about bumping CMake version? In the latter case, it's not too complex to compare actual compiler/linker command lines before and after upgrade to make sure that nothing was changed in an unexpected way.

[AlexandreRouma]

it's not too complex to compare actual compiler/linker command lines

It would have to be done for every CMake version currently in use by every distro. This goes against the entire reason why cmake has this version metadata.

[alexey-lysiuk]

it's not too complex to compare actual compiler/linker command lines

It would have to be done for every CMake version currently in use by every distro. This goes against the entire reason why cmake has this version metadata.

It was about libcorrect in this repository only.

[kerel-fs]

• libcorrect upstream is unchanged since 7 years, so the chances to upstream anything there are very slim, too slim for me to try. I assume there is a good reason why it is vendorized.
• The change required to cmake_minimum_required with CMake 4.0.0 will hit many repositories, yes. I'm not in a fan of this, but at least I can do my best and report this issue in projects I care about, here SDRPlusPlus. The workaround mentioned above will be dropped in a future version, and then there is no choice than to accept what CMake decided.

Thank your for SDR++!

[gvanem]

How is MSVC supposed to build and use this libcorrect. Some programs does not compile due to such VLA-stuff:

size_t msg_len = 2;

void find_poly(size_t rate, size_t order, libfec_decoder_t libfec, correct_convolutional_polynomial_t *poly) {
 ...
 uint8_t msg[msg_len];