Hi Caleb, Caleb Ristvedt <[email protected]> writes:
> Maxim Cournoyer <[email protected]> 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
