Multiple CI build failures due to incompatibility between cmake 4.x and mbedtls 2.x (we need to bump to mbedtls 3.x)

[diminDDL]

I have a CI/CD pipeline set up for one of my projects that pulls the latest version of Ubuntu and installs all required build tools through apt, and then pulls in pico-sdk and uses it to build stuff.

Today I saw the pipeline fail with the following error:

...
[ 11%] Performing configure step for 'picotoolBuild'
Not searching for unused variables given on the command line.
-- The C compiler identification is GNU 13.3.0
-- The CXX compiler identification is GNU 13.3.0
-- Detecting CXX compiler ABI info
-- The CXX compiler identification is GNU 13.3.0
-- Detecting C compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Configuring done (0.5s)
-- Generating done (0.0s)
-- Build files have been written to: /home/runner/work/[REDACTED]/build/pioasm
[ 12%] Performing build step for 'pioasmBuild'
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
.//home/runner/work/[REDACTED]/build/_deps/picotool/
-- Using the single-header code from /home/runner/work/[REDACTED]/build/_deps/picotool-src/lib/nlohmann_json/single_include/
CMake Error at /home/runner/pico/pico-sdk/lib/mbedtls/CMakeLists.txt:23 (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.


-- Configuring incomplete, errors occurred!
make[2]: *** [CMakeFiles/picotoolBuild.dir/build.make:101: picotool/src/picotoolBuild-stamp/picotoolBuild-configure] Error 1
make[1]: *** [CMakeFiles/Makefile2:2464: CMakeFiles/picotoolBuild.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[100%] Built target pioasm
[ 13%] Performing install step for 'pioasmBuild'
[100%] Built target pioasm
Install the project...
-- Install configuration: "Release"
[ 14%] Completed 'pioasmBuild'
[ 14%] Built target pioasmBuild
make: *** [Makefile:91: all] Error 2
Error: Process completed with exit code 2.

This happened because the CI/CD setup installed cmake 3.28.3-1build7.

As far as I understand doing something like cmake_minimum_required(VERSION 3.5...3.27) (which is used elsewhere in the sdk) in the relevant files should fix this.

I am unsure if this should be reported here or somewhere else, if so I would be grateful if someone pointed me towards the right place to report this.

Thank you.

[lurch]

How bizarre that upgrading to a newer version of CMake causes the entire build to fail 😖

lib/mbedtls/CMakeLists.txt comes from a submodule i.e. https://github.com/Mbed-TLS/mbedtls
It looks like we're currently using MbedTLS 2.28.8, and apparently there's also a MbedTLS 2.28.10 which "is the last release of the 2.28 LTS". And unfortunately even mbedtls-2.28.10 still uses cmake_minimum_required(VERSION 2.8.12) in https://github.com/Mbed-TLS/mbedtls/blob/mbedtls-2.28.10/CMakeLists.txt
(i.e. this bug won't be fixed until we bump to the Mbed TLS 3.6 series)

Are you able to force your CI to use an older version of CMake in the meantime?

[diminDDL]

Hello, thank you for the quick response. My CI/CD can use an older version of cmake just fine, I just wanted to notify the team about this issue that people would likely encounter more and more over time now that Ubuntu seems to ship this new version of cmake.

[peterharperuk]

I'm not entirely sure why we haven't updated mbedtls to mbedtls-3.x. It would probably be a good idea to keep in sync with Micropython.

[Daft-Freak]

At least the CMake version that causes this (4.0), was only released last week. Another point to add is that because the error happens in the picotool build, the suggested workaround of -DCMAKE_POLICY_VERSION_MINIMUM=3.5 doesn't work (presumably it doesn't make it that far down).

(Interestingly this is causing my actions to fail randomly, a retry usually fixes it)

[will-v-pi]

(Interestingly this is causing my actions to fail randomly, a retry usually fixes it)

GitHub runners don't all update at once, so some are on CMake version 3.x and some on version 4 - actions failing just depends on which one you happen to get

[Fortinbra]

Just wanted to tack on to this that the project I work with, GP2040-CE, which relies very heavily on the SDK, is now unable to build at all due to this Cmake issue, and it's not just MBed, but TinyUSB as well.

[arntsonl]

Here's our error for GP2040-CE

[  0%] Creating directories for 'ELF2UF2Build'
[  0%] Creating directories for 'PioasmBuild'
[  0%] Building ASM object pico-sdk/src/rp2_common/boot_stage2/CMakeFiles/bs2_default.dir/compile_time_choice.S.obj
[  0%] Building CXX object lib/CRC32/CMakeFiles/CRC32.dir/src/CRC32.cpp.obj
[  0%] Building C object lib/nanopb/CMakeFiles/nanopb.dir/pb_common.c.obj
[  0%] Building C object lib/nanopb/CMakeFiles/nanopb.dir/pb_decode.c.obj
[  0%] Building C object lib/nanopb/CMakeFiles/nanopb.dir/pb_encode.c.obj
[  0%] No download step for 'ELF2UF2Build'
[  0%] No download step for 'PioasmBuild'
[  0%] No update step for 'ELF2UF2Build'
[  0%] No update step for 'PioasmBuild'
[  0%] Linking ASM executable bs2_default.elf
[  0%] No patch step for 'ELF2UF2Build'
[  0%] No patch step for 'PioasmBuild'
[  0%] Performing configure step for 'ELF2UF2Build'
[  1%] Linking CXX static library libCRC32.a
[  1%] Performing configure step for 'PioasmBuild'
[  1%] Built target bs2_default
loading initial cache file /home/runner/work/GP2040-CE/GP2040-CE/build/pico-sdk/src/rp2_common/tinyusb/pioasm/tmp/PioasmBuild-cache-Release.cmake
-- Configuring incomplete, errors occurred!
CMake Error at 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.


gmake[2]: *** [pico-sdk/src/rp2_common/tinyusb/CMakeFiles/PioasmBuild.dir/build.make:[9](https://github.com/OpenStickCommunity/GP2040-CE/actions/runs/14188024940/job/39746754023#step:8:10)2: pico-sdk/src/rp2_common/tinyusb/pioasm/src/PioasmBuild-stamp/PioasmBuild-configure] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2443: pico-sdk/src/rp2_common/tinyusb/CMakeFiles/PioasmBuild.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[  1%] Built target CRC32
[  1%] Generating bs2_default.bin
[  1%] Generating bs2_default_padded_checksummed.S
[  1%] Built target bs2_default_padded_checksummed_asm
-- The C compiler identification is GNU [11](https://github.com/OpenStickCommunity/GP2040-CE/actions/runs/14188024940/job/39746754023#step:8:12).4.0
[  1%] Linking C static library libnanopb.a
[  1%] Built target nanopb
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done```

[will-v-pi]

Just wanted to tack on to this that the project I work with, GP2040-CE, which relies very heavily on the SDK, is now unable to build at all due to this Cmake issue, and it's not just MBed, but TinyUSB as well.

Looking at that output, you're still building with SDK 1.5.1 (the ELF2UF2Build target, and uppercase p in PioasmBuild), which is why you're seeing the pioasm error as well inside tinyusb - that was fixed in #1546

[Gadgetoid]

Welp. I just found my way onto this band-wagon too.

Currently between a rock and a hard place because GitHub is dropping support for the ubuntu-20.04 runner imminently (on the 15th April) with deprecation beginning today, and this error cropped up during a migration to ubuntu-24.04.