The ENetDTLSServer socket implementation should avoid reporting errors
during send and receive operations, unless the socket is effectively no
longer usable (and thus ENet should close it).
It will be included in the next release at some point.
- https://github.com/RenderKit/embree/issues 486
"fix output operator"
[ 30%] Compiling thirdparty/embree/kernels/common/accelset.cpp ...
In file included from thirdparty/embree/kernels/common/device.cpp:12:
In file included from thirdparty/embree/kernels/common/scene_curves.h:10:
thirdparty/embree/kernels/common/../subdiv/bezier_curve.h:138:56:
error: no member named 'u' in 'QuadraticBezierCurve<V>'
138 | return cout << "QuadraticBezierCurve ( (" << a.u.lower << ", "
<< a.u.upper << "), " << a.v0 << ", " << a.v1 << ", " << a.v2 << ")";
...
This avoids any assumption from the driver, which would otherwise select
a specific platform and potentially mess up everything, resulting
usually in a display server failure.
Our current Linux SDK for ARM32 from https://github.com/godotengine/buildroot
targets a relatively conservative baseline of neon-fp-armv8, and (at least based
on build issues I got) this doesn't seem to include hardware AES support.
Fixes#91352.
The `include/mbedtls/check_config.h` header file has a generic check
which requires `MBEDTLS_PLATFORM_C` to be defined on Windows when
building with MinGW and ancient MSVC versions.
The few mbedTLS files we include in builds without the module don't
really require anything from the mbedTLS platform file beside the
`mbedtls_platform_zeroize` function which we already override with a
custom one by defining `MBEDTLS_PLATFORM_ZEROIZE_ALT`.
So we simply add the same check and force the define in such case.
Keep module compatibility with mbedtls 2.x (old LTS branch).
A patch has been added to allow compiling after removing all the `psa_*`
files from the library folder (will look into upstreaming it).
Note: mbedTLS 3.6 finally enabled TLSv1.3 by default, but it requires
some module changes, and to enable PSA crypto (new "standard" API
specification), so it might be best done in a separate commit/PR.
