Maxim Cournoyer <maxim.courno...@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
