Re: can't get past commencement in test-env

[Ludovic Courtès]

Hi Caleb!

Caleb Ristvedt <address@hidden> skribis:

> 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

That’s one of the many reasons we strongly recommend against non-chroot
builds.  :-)

In the daemon you’re working on, we have the opportunity to take
advantage of user namespaces for isolated builds, so there’s no reason
not to do isolated builds.

> 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.

Building with ./test-env is costly, because you don’t get any
substitutes.  It’s likely to fail due to the lack of isolation, as you
noticed, and it’s also likely to fail for other reasons, such as
file/socket name length limits.

That said, it Wouldn’t Be That Hard™ to tack user namespace support to
the C++ code base, if you feel like it.

Thoughts?

At any rate, I’d recommend against fiddling with ‘genmultilib’ or any
such thing, because that would be just one of the many problems you’d
face in non-isolated builds.

Thanks,
Ludo’.