Otherwise we run into situations where commits to stable branches
induce very long build times, as they have to basically build from
scratch but also invalidate the cache for future commits on the
master branch.
This commit also makes the cache folder branch-specific, but since
it's still limited to 1 GB of total cache size, we don't enable it
for non-master, as we would still run into issues with non-master
build invalidating the master cache.
(cherry picked from commit b021bdbf1f)
The rationale for keeping those shared by default is that they're typical
dependencies found on any Linux system, and it saves compilation time and
binary size to link their dynamically.
But since official builds default to all-builtin, and Debian/Ubuntu still
don't have libpng16 (which we now require) readily available on all their
supported releases, it's simpler to bundle all the things.
This does not change the fact that those dependencies *can* be unbundled
on Linux, it's only the default option changing.
(cherry picked from commit 1769cbc0e2)
For 2.1, also building by default against bundled openssl.
Emscripten used not to error out on those warnings, but this behaviour changed
recently, so we revert it to be able to compile as we used to for previous 2.1.x
releases. It would be good to fix those undefined symbols though.
From August 1, 2019, Google Play requires that all new apps and app updates
include 64-bit versions, so we enable ARM64 by default.
IINM support for x86 and x86_64 is still be optional, so not enabling them
out of the box.
Part of #25030.
(cherry picked from commit 9e820cdf20)
Like arm64v8, this is only supported by API 21 and later,
so we enforce 21 as min API for x86_64.
Part of #25030.
(cherry picked from commit 7f4ee36469)
New contributors added to AUTHORS:
@dragmz, @fire
Thanks to all contributors and donors for making Godot possible!
[ci skip]
(cherry picked from commit 284b56f2fb)
Yesterday, when playing around with my network code, I realized there is
a security issue in decode_variant, at least when decoding PoolArrays.
Basically, the size of the PoolArray is encoded in a uint32_t, when
decoding it, that value is cast to int when comparing if the packet is
actually that size causing numbers with MSB=1 to be interpreted as
negative thus always passing the check. That same value though, is used
as uint32_t again to resize the output vector. For this reason, sending
a malformed packet with declared type PoolByteArray and size of 2^31(+x)
causes the engine to try to allocate 2+GB of pool memory, causing the
engine to crash.
This patch is a backport of the one initially written for the master
branch.
Extending on b68222e4e7 to ensure that it still
has the exact same behaviour as the previous code, as discussed with @hpvb.
(cherry picked from commit 03e11c13bf)