Without NO_SESSION_CACHE_REF, wolfSSL_get_session() returns a reference into the process-global client cache rather than a session object. That reference is valid only while the slot it names still holds the session it was issued for, which the caller cannot observe, so the safe use of the API is the one the macro selects. Only the integration recipes defined it, and none of them for that reason: --enable-opensslextra and --enable-opensslall, which is what an application written against SSL_get_session() reaches for, left it unset. settings.h now defines NO_SESSION_CACHE_REF unless WOLFSSL_SESSION_CACHE_REF is defined, so every build selects it, including the user_settings.h, IDE and bare-metal builds that have no configure step. Putting the rule in the header rather than only in configure and CMake means no project has to add a macro to keep the safe behaviour, and the ones that want the deprecated reference ask for it instead. --enable-session-cache-ref and -DWOLFSSL_SESSION_CACHE_REF=yes define that opt-in macro, and options.h records it alongside the negative one so an application cannot disagree with the library it links. A build that opts in warns at compile time and the warning names WOLFSSL_SESSION_CACHE_REF_WARNED, which silences it while keeping the path. It sits inside the NO_SESSION_CACHE region, so a build without a session cache and a wolfCrypt-only build stay quiet, and it takes the #warning / #pragma message form already used for WOLFSSL_KEYLOG_EXPORT_WARNED. The recipes that define NO_SESSION_CACHE_REF on their own keep doing so and still win over the option. Both build systems say so rather than leaving a reported option disagreeing with the build: configure warns and clears its summary line, CMake warns and syncs the cached option. configure also treats TITAN_SESSION_CACHE as a conflict, because settings.h derives the macro from it and that never reaches the compile line for a flag scan to find. The os-check session-cache-ref entry existed because --enable-opensslextra left the macro unset. It now asks for the reference path explicitly, or test_wolfSSL_client_cache_id_overwrite would skip and the generation check added with it would be covered nowhere. Anything migrating has one lifetime difference to mind: the deprecated reference stayed valid after wolfSSL_free(), the session object does not, so code holding the result of wolfSSL_get_session() past the WOLFSSL it came from has to move to wolfSSL_get1_session() and wolfSSL_SESSION_free().
wolfSSL CMake
This directory contains some supplementary functions for the CMakeLists.txt in the root.
See also cmake notes in the INSTALL documentation file. When building with autoconf/automake, CMake package files are installed by default under $(libdir)/cmake/wolfssl to support find_package(wolfssl). Disable with ./configure --disable-cmake-install.
If new CMake build options are added cmake/options.h.in must also be updated.
For more information on building wolfSSL, see the wolfSSL Manual.
In summary for cmake:
# From the root of the wolfSSL repo:
mkdir -p out
pushd out
cmake ..
cmake --build .
# View the available ciphers with:
./examples/client/client -e
popd
CMake Presets
The CMakePresets.json; see [cmake-presets(https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html)
-
Cross-platform and cross-IDE.
-
Standardized CMake feature (since CMake 3.19+, recommended after 3.21).
-
Works in Visual Studio, VS Code, CLI, CI systems, etc..
Visual Studio Settings
There's also a Visual Studio specific file: CMakeSettings.json. This the file that supports the GUI CMake settings.
See the Microsoft CMakeSettings.json schema reference
Visual Studio (2022 v17.1 and later):
-
Prefers
CMakePresets.jsonif it exists. -
Falls back to
CMakeSettings.jsonif no presets are found. -
Lets you override or extend presets via
CMakeSettings.json.
Recommendations:
-
Use
CMakePresets.jsonto define shared, cross-platform presets. -
Use
CMakeSettings.jsonto define Visual Studio-specific overrides, like:- Custom output directories
- Specific environment variables
- *UI-related tweaks