Hi Ludovic, Ludovic Courtès <[email protected]> writes:
> Hi Caleb! > > Caleb Ristvedt <[email protected]> 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
