can't get past commencement in test-env

[Caleb Ristvedt]

gcc-boot0 in (gnu packages commencement) compiles subtly differently
when built in a chroot (for example, by an installed daemon) compared to
when built without root privileges (for example, in
test-env). Specifically, the presence of this line in the build log:

../../gcc-5.5.0/gcc/genmultilib: ./tmpmultilib: /bin/sh: bad interpreter: No 
such file or directory

This doesn't get caught by the patch-shebangs or
patch-generated-shebangs phases because tmpmultilib is both generated
and immediately executed by genmultilib in order to, I kid you not,
implement recursion in a portable manner by having tmpmultilib run
itself. Somehow this works out in the chroot case despite it failing to
run, but in the non-chroot case /bin/sh actually exists, at least on
Guix System. This ultimately causes two different compilers to be
created in the two cases. In the chroot case, 'g++
-print-multi-os-directory' simply gives

.;

while in the non-chroot case, it gives

../lib64

This means that when the bootstrap continues, libstdc++ is built with
its outputs going to different locations (lib/ or lib64/) depending on
which of the two compilers builds it. gcc-final assumes it will be in
lib, and so it can't find it if libstdc++ was built with a gcc-boot0
built without a chroot.

I don't know much about multilib stuff, but it would seem that the
"correct" output from gcc's perspective would be one in which its
contemplation of the matter isn't interrupted by a "bad interpreter"
error. But that's also the opposite of the assumptions we currently
make, and changing it would require both rebuilding the world and
modifying several packages.

At the same time, I'd like to be able to test building derivations in
test-env without needing to run it as root (and modifying test-env
slightly to remove the --disable-chroot, and choosing between running
all those builders as root (yikes) or risking interfering with my
installed daemon by using the same build group). I'd also appreciate it
if others could test building packages in test-env easily, as it catches
an entire class of errors that usually isn't caught otherwise (typically
errors caused by assumptions about where the store is). The same issues
that plague test-env will also occur in an unprivileged install.

What is The Right Thing™ to do here?

- reepca