can't get past commencement in test-env

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

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 <caleb.ristvedt@cune.org> 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

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

[Caleb Ristvedt]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

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

Thanks.

> That's an interesting find! What exactly is the 'test-env'? Do you mean
> an environment created using 'guix environment --pure' ?

No, test-env is the name of a script generated in the process of
compiling guix. It's used in running the tests run by 'make check'. The
main feature is that it runs its own daemon with its own store in a
subdirectory of the guix source directory named test-tmp/store, so tests
involving the daemon can be run without needing it already
installed. Other than that, it works like pre-inst-env for the most
part.

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

genmultilib takes many arguments, passed to it from the makefile. I'm
sure there's a combination of values for which it will do what we
currently do. To work correctly, though, the script will definitely have
to be patched so that the script it generates has the correct
interpreter.

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

Aye. Changing the builder for gcc-boot0 will cause a full-world rebuild,
so I suppose it should go in core-updates?

- reepca

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

[Maxim Cournoyer]

Hi Caleb,

Caleb Ristvedt <caleb.ristvedt@cune.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Hello Caleb,
>>
>> Sorry if this answer is late; I noticed nobody had replied yet, so
>> thought I'd try.
>
> Thanks.
>
>> That's an interesting find! What exactly is the 'test-env'? Do you mean
>> an environment created using 'guix environment --pure' ?
>
> No, test-env is the name of a script generated in the process of
> compiling guix. It's used in running the tests run by 'make check'. The
> main feature is that it runs its own daemon with its own store in a
> subdirectory of the guix source directory named test-tmp/store, so tests
> involving the daemon can be run without needing it already
> installed. Other than that, it works like pre-inst-env for the most
> part.
>
>>> 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.
>
> genmultilib takes many arguments, passed to it from the makefile. I'm
> sure there's a combination of values for which it will do what we
> currently do. To work correctly, though, the script will definitely have
> to be patched so that the script it generates has the correct
> interpreter.
>
>> 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.
>
> Aye. Changing the builder for gcc-boot0 will cause a full-world rebuild,
> so I suppose it should go in core-updates?
>
> - reepca

core-updates is currently being stabilized (it's in a frozen state).
Perhaps it's best to hold on to publishing this change until
core-updates has been merged to master or else base it on top of the
'core-updates-next' branch, which is used in place of core-updates in
those circumstances.

Maxim

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

[Ludovic Courtès]

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.

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

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

[Maxim Cournoyer]

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

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

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> 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

[...]

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

Well, apparently it’s not an issue in practice.  :-)

But yeah, we could investigate what happens in chrooted builds and see
whether genmultilib not finding /bin/sh has consequences we hadn’t seen
so far.

Thanks,
Ludo’.