This commit adds `hasSharedLibraries` to `lib.systems`.

We need `plat.hasSharedLibraries` in order to know whether or not to
expect `gcc` (and many other tools) to emit shared libraries (like
`libgcc_s.so`).  Many of the GNU build scripts are smart enough that
if you configure them with `--enable-shared` on a platform (such as
`arm-none-eabi`) that doesn't support dynamic linking, they will
simply skip the shared libraries instead of aborting the
`configurePhase`.  Unfortunately the missing shared libraries in the
final build product cause very hard-to-troubleshoot problems later
on.

The alternative to introducing `hasSharedLibraries` would be to set
`isStatic` in these situations.  However doing so causes
`make-derivation.nix` to insert `-static` between the `pname` and
`hostPlatform` suffix, which is undesirable.

If at some point in the future we eliminate the `-static` suffix,
then `hasSharedLibraries` can be made equal to `!isStatic`.

(cherry picked from commit 6980e6b)

(cherry picked from commit e41f217)

…rgetLibc

This commit allows `gccCrossStageStatic` to build dynamically-linked
libraries.  Since is no longer restricted to building static
libraries its name is no longer appropriate, and this commit also
renames it to the more-accurate `gccWithoutTargetLibc`.

By default, you can't build a gcc that knows how to create dynamic
libraries unless you have already built the targetPlatform libc.

Because of this, our gcc cross-compiler is built in two stages:

  1. Build a cross-compiler (gccCrossStageStatic) that can build
     only static libraries.

  2. Use gccCrossStageStatic to compile the targetPlatform libc.

  3. Use the targetPlatform libc to build a fully-capable cross
     compiler.

You might notice that this pattern looks very similar to what we do
with `xgcc` in the stdenv bootstrap.  Indeed it is!  I would like to
work towards getting the existing stdenv bootstrap to handle cross
compilers as well.  However we don't want to cripple `stdenv.xgcc`
by taking away its ability to build dynamic libraries.

It turns out that the only thing gcc needs the targetPlatform libc
for is to emit a DT_NEEDED for `-lc` into `libgcc.so`.  That's it!
And since we don't use `gccCrossStageStatic` to build anything other
than libc, it's safe to omit the `DT_NEEDED` because that `libgcc`
will never be loaded by anything other than `libc`.  So `libc` will
already be in the process's address space.

Other people have noticed this; crosstool-ng has been using this
approach for a very long time:

  https://github.com/crosstool-ng/crosstool-ng/blob/36ad0b17a732aaffe4701d5d8d410d6e3e3abba9/scripts/build/cc/gcc.sh#L638-L640

(cherry picked from commit 2affd45)

This commit renames the `crossStageStatic` argument to the `gcc`
expression to `withoutTargetLibc`.  See previous commit for details.

(cherry picked from commit 443dfc4)

We want a `libgcc_s.so` to be built by the first stage
cross-compiler (withoutTargetLibc), since that is the compiler which
will compile the target libc.

This commit accomplishes that, by making three changes:

1. Replacing the `targetPlatform.libc == "msvcrt" &&` conditional
   with `enableShared`, so that the code which cross-build
   `libgcc_s.so` is used for all cross compilers capable of emitting
   shared libraries.

2. Removing the `targetPlatform == hostPlatform` guard from the code
   which produces the `libgcc` output.

3. Looking for build products in in "lib/${targetPlatform.config}/"
   rather than "lib/", so we will find them when cross compiling.

(cherry picked from commit 63305d0)

This commit is reverted in NixOS#240596 (which must go to staging).

(cherry-picked from commit 96a2f1b)