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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Caleb!
>
> Caleb Ristvedt <caleb.ristvedt@cune.org> 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.

Disregarding the value of chrooted isolated builds, I think Caleb found
out a valid issue in the Guix (chrooted) build of GCC (the failure to
find /bin/sh leads to errors in genmultilib producing the library output
'lib' rather than '/lib64').

Do you think it's worthy of fixing?

Maxim