> There are many projects that don't have a configure script that finds 
gcc.

> +                       ;; Create 'cc' so that one can use it as a drop-in
> +                       ;; replacement for the default tool chain and have
> +                       ;; configure scripts find the compiler.  Note that
> +                       ;; 'c++' is already present, no need to symlink it.
> +                       (symlink "gcc" (string-append out "/bin/cc"))

That doesn't work.  Sure, those configure scripts will find _a_ 
compiler, but it will be the _wrong_ compiler when cross-compiling, so 
for such packages you need to set CC=(cc-for-target) instead, which 
eliminates the need for 'cc'.  Furthermore, the lack of a ‘cc’ binary 
ensures that those configure scripts fail, which helps 
detecting/preventing this cross-compilation issue.

IOW, I think the true issue is the use of 'cc' in those configure 
scripts, not the lack of 'cc' in Guix.

(I have a patch at https://issues.guix.gnu.org/65426 for detecting this 
kind of compilation issue, albeit in #:make-flags instead instead of 
#:configure-flags and it doesn't look inside configure scripts.)

Also see <https://issues.guix.gnu.org/28629>, though that one is pretty 
useless because it doesn't _why_ the decision was made.

 > [...] Also makes it more symmetric with the clang-toolchain, that 
also does this.

If you are aiming for symmetry, I would instead propose removing 'cc' 
from clang-toolchain.  OTOH, cross-compilation in clang works somewhat 
differently (extra arguments instead of a separate binary IIUC), so 
perhaps Clang's cc is fine (assuming that the (equivalents of) Makefiles 
actually bother passing those extra arguments, which I doubt ...)

Best regards,
Maxime.