gcc: Place target system libraries in a separate output

[eamsden]

Describe the bug
Cross-compiled gcc 9, used in cross-compiling stdenv in master, puts target libraries in its out output, forcing programs that link against the GCC runtime to depend on the GCC closure.

For armv7l, this results in outputs built with the cross-compiling stdenv depending on the gcc out output, which comes to 748 MB not counting its own closure. The actual set of target-system libraries, in ``armv7l-unknown-linux-gnueabihf/lib`, comes to 35MB.

To Reproduce
Steps to reproduce the behavior:

1. Build a cross-compiling gcc: nix-build -A pkgsCross.armv7l-hf-multiplatform.buildPackages.gcc-unwrapped
2. Investigate result/<system>/lib and note libraries for target system are present in that path under the out output.
3. Obtain the lib output nix-build -A pkgsCross.armv7l-hf-multiplatform.buildPackages.gcc-unwrapped.lib
4. Test .so files with the file utility, note that they are only for the compiler's host platform, not its target platform.
5. Build e.g. nix cross-compiled: nix-build -A pkgsCross.armv7lhf-multiplatform.nix
6. View the runtime dependency closure sorted by size: nix-store -qR result | xargs du -d0 -h -c | sort -h

Expected behavior

Cross-compiling GCC should place target system libraries in a separate output, so programs which it dynamically links with those libraries do not pull all of GCC into their runtime closure.

Additional context

This is a continuation of the investigation in #81153, as to why cross-compiled nix has build-system dependencies in its runtime closure.

Metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 5.5.2, NixOS, 20.03pre-git (Markhor)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.2`
 - channels(root): `"nixos-19.09.1965.274e095f761"`
 - channels(edward): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
- pkgsCross.armv7l-hf-multiplatform.buildPackages.gcc-unwrapped
# a list of nixos modules affected by the problem
module:

[eamsden]

@flokli I'm pretty sure this is the reason build-system paths are still making it into the closure for cross-compiled nix, just not sure how to fix it.

[eamsden]

ccing @Synthetica9 as the gcc 9 maintainer

[lopsided98]

#58606 should fix this

[eamsden]

@lopsided98 looks like it, though some libraries for GCC's host platform (i.e. the build platform for things built with that gcc) would still be in the lib output, no? I'll try cross-compiling Nix against that PR and see if there is still build-system pollution in the closure.

[eamsden]

This seems to be a dup of #58501 but that was closed...not sure why.

[stale]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

[flokli]

This still should be desirable. @matthewbauer, was #59787 probably not enough?

[matthewbauer]

Right - that was not enough, but e1831eb#diff-c9fb175e04caebec67031e96e3dc5f20 should be.

[lopsided98]

Yes, I can confirm that; I recently built a minimal cross-compiled NixOS system with no build arch references.