There's a lot of duplication between the cross-building stuff for gcc and the Linux stdenv bootstrap.
Similarly, in libiconv's setup, the same logic is repeated twice, once for cross-building and once for stdenv.
Also, consider the dropbox package, which checks stdenv.system to see which binary to download. Supposing that one was cross-compiling a NixOS system from OS X, this is incorrect; stdenv.system would be x86_64-darwin, while the desired value x86_64-linux would not even be available in the current crossSystem attributes. (The closest is config, which would be "x86_64-unknown-linux-gnu"). On the other hand, the url contains the arch, which is present in crossSystem, but not in stdenv.

In other words, it's unclear what attributes are supposed to be checked for platform-dependent behavior, and the set of attributes available is inconsistent between cross-builds and normal builds. This should be decided upon and the results documented somewhere (e.g. nixpkgs manual).

Also see #4855 for a related discussion on cross-building dependencies, #1928 for requested stdenv attributes and cross-building TODO's that never happened, #6221 and #7334 for more stdenv attributes, #8081 for bootstrap tools scope creep, #3574 and #7384 mentioning dedicated Hydra job for bootstrap tools, #6952 for a possible alternative to our current bootstrapping approach, #5944 for why cross-compiling only works with gcc, #4963 for ideas on NixOS (as opposed to nixpkgs) cross-compiling, #2817 for odd stdenv overrides behavior, and #4998 for the likely end state of this issue.

I propose setting system to be the crossSystem-style attribute set for the targeted system, and combining bootStdenv and crossSystem into bootSystem, representing the host system on which the builders are run.