Fixup to work with mbedtls 3.x #219
Conversation
Allow access to the private variables required, and some changed function signatures Maintain compatibility with mbedtls 2.x using #ifs
If mbedtls 2.x is EOL, and mbed 3.x is also LTS, do we need to bother maintaining compatibility with mbedtls 2.x? 🤔 |
|
I think it's best to maintain it for now, so picotool 2.1.x can be built with any SDK 2.1.x |
Ahhh, perhaps I was wrong to assume that the pico-sdk and pictool versions increment in lock-step? In which case yeah there's obviously no harm in maintaining compatibility with multiple versions. |
They do increment in lock step, but don't necessarily require the latest version of each other - for example picotool 2.1.2 can be built with pico-sdk 2.1.0, if you want the speedups in picotool 2.1.2 but don't want to upgrade your SDK yet. So probably best to maintain compatibility for now. |
Ah cool 👍 With all the intertwined PRs in |
CMake 4.0 has been released, which requires Mbedtls 3.x. This is because Mbedtls 2.x sets a min CMake version of 2.8.12, but CMake 4.0 throws an error if the min version is < 3.5. This is already causing some picotool CI failures, as some runners seem to have the latest CMake (https://github.com/raspberrypi/picotool/actions/runs/14196997735/job/39774407801#step:8:32). This needs updating in the SDK too, see raspberrypi/pico-sdk#2391
The fix is to allow access to the private variables required, and some changed function signatures. This maintains compatibility with mbedtls 2.x using #ifs on the MBEDTLS_VERSION_MAJOR.