distutils was dropped from Python 3.12. Fortunately, our usage of
android-ndk only relied on distutils.dir_util.copy_tree() in
build/tools/make_standalone_toolchain.py which
is easy to replace with shutil.copytree(). That is done via a small
patch.
Note that there are more references to distutils in the following
files but it looks like our CI/CD flows aren't affected by those:
sources/third_party/shaderc/third_party/spirv-tools/utils/generate_registry_tables.py
sources/third_party/vulkan/src/scripts/update_deps.py
prebuilt/linux-x86_64/bin/python2.7-config
prebuilt/linux-x86_64/bin/python-config
prebuilt/linux-x86_64/bin/python2-config
various files under prebuilt/linux-x86_64/lib/python2.7/
python-packages/fastboot/setup.py
python-packages/adb/setup.py
base_deps_meta_version was bumped so that the base dependencies archives for CI
workflows are recreated (we need only the Windows flavours of the
archives updated but such surgical intervention is not supported).
When releasing libzim and libkiwix, we use config native_mixed with is a
mix of static and dynamic linking:
- Dependencies are build as static libraries.
- Released projects (libzim/libkiwix) are build as dynamic libraries,
statically linked to dependencies.
This way, we have only one `.so` file which contain all our needed symbols.
However, this logic is "local" to each project.
This mean that libkiwix is linked **statically** to libzim.
So libkiwix.so is containing libzim symbols.
But on "java-libkiwix", we are both linking to libzim.so and libkiwix.so.
If the version of the (dynamically) used libzim.so is not the same that the
version on which we have (statically) linked libkiwix.so, we end with
symbols of two different versions being loaded and conflicting.
So let's rebuild libkiwix with last version of libzim to avoid this conflict.