As explained in the comment, this ensures that stage4-coreutils does
not leak a reference to the bootstrap-files by way of libgmp.  This
will allow the next patch in this series to build stage4-coreutils
using a dynamically-linked (rather than statically-linked) libgmp.

The usage of `makeStaticLibraries` in stdenv/linux/default.nix is
prefaced by this comment:

  # Link GCC statically against GMP etc.  This makes sense because
  # these builds of the libraries are only used by GCC, so it
  # reduces the size of the stdenv closure.

However "these builds of the libraries are only used by GCC" is not
actually true.  As currently written, the stage4 coreutils links
against these customized, static-ified libraries.

Beside the fact that the code doesn't actually do what it says, this
causes other problems as well.  One example is #168983, which arises
because have a dynamically-linked binary (coreutils) which is built
from statically-linked libraries (libgmp.a); doing this causes mayhem
on platforms where `-fstack-protector` needs an auxiliary
`libssp.{so,a}` library; we end up with link failures because some
parts of the resulting binary want `libssp.so` and other parts want
`libssp_nonshared.a`.

Let's make the code actually do what the comment says, by moving these
definitions into the `gcc-unwrapped` override.  This will cause the
stage4-coreutils to link against libgmp dynamically, rather than
statically.  For this reason this commit depends on the previous
commit, which allows that to be done without creating a forbidden
reference from stdenv-final to the bootstrap-files.

During stdenv bootstrapping, coreutils is built twice.  This makes
troubleshooting very difficult, because both packages have
name="coreutils", so it is a hassle to figure out "which coreutils am
I using / is not building"?

The first of these builds is used only in stage4, and is not part of
the final stdenv.  Let's label that one with a different `name`
attribute to make it obvious which is which.

Co-authored-by: sternenseemann <sternenseemann@systemli.org>

A bug in libgcc which manifests when building static binaries using
musl-libc was fixed in gcc 11.1.0, but the fix has not been backported
to gcc 10.  This commit cherry-picks the commit from upstream and
applies it in the case (isPower64 && isMusl) where it matters:

  https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=cda41ce0e8414aec59e6b9fbe645d96e6e8193e2

This commit causes powerpc*-*-gnu to be configured with 64-bit
IEEE-compliant `long double` (the same as ordinary `double`) rather
than the nonstandard, non-IEEE "IBM double" format from AIX.  Support
for using only IEEE 128-bit doubles in glibc is not yet ready.

This resolves several package test failures caused by weird
nonstandard floating-point semantics.  It also eliminates a lot of
difficulties that arise when using glibc-linked tools to compile for
musl-libc and vice versa.

There is a long comment included in gcc/common/platform-flags.nix
explaining the situation and the reasoning.