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

[Maxim Cournoyer]

Hello Caleb,

Sorry if this answer is late; I noticed nobody had replied yet, so
thought I'd try.

Caleb Ristvedt <address@hidden> writes:

> 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 an interesting find! What exactly is the 'test-env'? Do you mean
an environment created using 'guix environment --pure' ?

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

Perhaps the best fix would be to find a way to tell gcc to always use
"/lib" for its library directory?  Perhaps possible via a configure
flag?  Otherwise by patching the script.

Until we have a need for separating /lib and /lib64 (I guess if we
wanted to produce 32 bits variants of packages, that could be useful),
we can postpone the big change of using the "correct" library path.

HTH!

Maxim