GCCBootstrap: Bump libtapi version

[Keno]

Upgrades libtapi to the latest version in
https://github.com/tpoechtrager/apple-libtapi, which in particular
picks up support for the v4 format for TAPI, which is used in
the macOS 11 SDK.

[Keno]

tpoechtrager/apple-libtapi#16

[Keno]

That said, maybe we shouldn't be building LLVM tools for this copy of llvm in the first place. Or maybe we should see if we can just build libtapi with our regular LLVM build and avoid building LLVM again.

[Keno]

We're also building all the backends, which is entirely unnecessary. Also, we're building one copy of this for each GCC version, which we don't need either. Not necessarily something we need to fix now, but worth revisiting in the future.

[staticfloat]

Is this patch no longer necessary?

[Keno]

no

[staticfloat]

When I originally glued this all together, the LLVM build that we make was not compatible with libtapi, I don't think. Also, we don't build just one LLVM version; we build multiple versions and swap them out, independently of the GCC version. Somehow I don't think libtapi is going to be happy with having LLVM 6 at one moment and LLVM 10 the next.

Since libtapi isn't changing from GCC version to GCC version, I think perhaps what we should do is extract this out into the PlatformSupport shard, and build it only once for each Darwin target, then see if we can link against it nicely in GCCBoostrap.

[Keno]

Putting it in PlatformSupport seems fine. I understand why it's in GCCBootstrap at the moment, since it basically replaces binutils, but those do vary with GCC version, while on Darwin, we only support one version of the linker (and libtapi).

[staticfloat]

I understand why it's in GCCBootstrap at the moment, since it basically replaces binutils, but those do vary with GCC version, while on Darwin, we only support one version of the linker (and libtapi).

Yeah..... perhaps the truly right way to do this is to go back to a separate Binutils_jll that we grab the appropriate version of for each GCC shard.