When native-compiling, gcc will install libraries into:

  /nix/store/...-$targetConfig-gcc-$version-lib/lib

When cross-compiling, gcc will install libraries into:

  /nix/store/...-$targetConfig-gcc-$version-lib/$targetConfig

When cross-compiling, we intended to create a link from $lib/lib to
$lib/$targetConfig, so that downstream users can always safely
assume that "${lib.getLib stdenv.cc.cc}/lib" is where the gcc
libraries are, regardless of whether `stdenv.cc.cc` is a cross
compiler or a native compiler.

Unfortunately, there were two problems with how we were trying to
create these links:

1. The link would be created only when `enableLibGccOutput==true`

2. The link was being created from the incorrect source
   `$lib/lib/lib` instead of `$lib/lib`.

Both of these mistakes are my fault.  This commit corrects them by
creating the link using `ln -Ts` (which is more predictable) and by
creating the link from `gcc/common/builder.nix` rather than from
`gcc/common/libgcc.nix`.

workaround bug in cross-compilation / meta.getExe

cudaPackages.autoAddCudaCompatRunpathHook: correct meta.platforms reference

cudaPackages.backendStdenv: use coreutils from buildPackages when cross-compiling

…about callPackage

…patRunpathHook

…ts about callPackage

…pattern

Since, even under cross-compilation, we evaluate this flag on multiple platforms, it makes more sense to move the platform check out of the throw condition
and into the boolean return value. The alternative is to restrict all uses of this value to locations which gaurd evaluation so it does not occur when the
host platform is still x86_64.

…veBuildInputs

…ostPatch phase

…body like other setup hooks

…to cuda_cudart

…nable structuredAttrs

… output