Update bundled dependencies and tooling

[madig]

While I'm at it.

[madig]

I'm gonna have to stop here because actually, the FT/HB build steps are broken. The current macOS/ARM64 builds just contain x86_64, meaning that M1 building doesn't work at all.

[madig]

Ok, @anthrotype discovered an easy fix for the macOS ARM64 build, but we still get HB linker errors :)

[anthrotype]

for some reasons, after updating to Harfbuzz 4.2.0, we now get a linker error about undefined symbols that belong to the libc++, but only on macOS, the Linux and Windows builds work like before.

https://github.com/rougier/freetype-py/runs/5836851904?check_suite_focus=true#step:4:496

The symbols seem to come from AAT-specific code in harfbuzz, hence maybe the mac-only build failure.

Now, simply adding -lc++ to the linker command which generates the libfreetype.dylib shared libray fixes the error. This patch below would be the cmake equivalent of that:

diff --git a/setup-build-freetype.py b/setup-build-freetype.py
index 289f7f6..707cc04 100644
--- a/setup-build-freetype.py
+++ b/setup-build-freetype.py
@@ -194,6 +194,7 @@ shell(
     '-DPKG_CONFIG_EXECUTABLE="" '  # Prevent finding system libraries
     '-DHARFBUZZ_INCLUDE_DIRS="{}" '
     "-DSKIP_INSTALL_HEADERS=ON "
+    '-DCMAKE_SHARED_LINKER_FLAGS="-lc++" '
     "{} ..".format(harfbuzz_includes, CMAKE_GLOBAL_SWITCHES),
     cwd=build_dir_ft,
 )

However, I'm not sure if this is the right fix, or if this is actually a bug in harfbuzz. As far as I know, one should not need to link in the c++ standard library when linking to harfbuzz from C code (like freetype does and hence freetype-py). I'll ask the harfbuzz maintainers for confirmation.

[anthrotype]

I guess we'll have to wait until https://github.com/harfbuzz/harfbuzz/pull/3527 is released

[anthrotype]

would be nice to have a release with this, it would be the first with universal2 wheels supporting both macos intel x86_64 and ARM64 (M1)