Pierre Neidhardt <[email protected]> skribis:
> Hi Konrad, > >> I am trying to figure out why sbcl-numcl fails to build since the update >> to SBCL 2.0.2. See here for a typical build log: >> >> http://ci.guix.gnu.org/build/2339924/details >> >> What happens is that SBCL runs out of heap space and stops. However, I >> can load numcl into SBCL 2.0.2 perfectly well when I load it via ASDF >> under my own user account. >> >> Therefore I suspect one of the following three possible causes: >> >> 1. The build daemon runs with memory restrictions that are too severe >> for building binaries for numcl. > > Hmmm, my intuition is that it would be surprising considering we build > very heavy packages. > >> 2. Building binaries with SBCL takes more heap space than merely >> loading a system from source via ASDF. > > I think probably not. However there are different ASDF operation. In the > Guix build system we use "program-op" which does not behave like the > default operation when loading a package. This could be a factor here. > >> 3. Guix' build systems does something that either limits heap space >> or causes SBCL to require more of it. >> >> Does anyone have an idea on how to proceed to fix the problem? > > Can you reproduce with SBCL 2.0 or SBCL 1.5? > Maybe report this issue to the SBCL issue tracker, they will probably > know what's going on. > > Cheers! In case the problem is that newer SBCL versions really need more memory during compilation, we could pass "--dynamic-space-size" to "make.sh" when building SBCL to increase the maximum heap size (1 Gb by default). I tried rebuilding SBCL with "--dynamic-space-size=2Gb" and I was able to compile sbcl-numcl. IIRC, compiling the clml and mgl libraries requires a 4Gb max heap. So if one day we want to package them in Guix we will need to use a bigger default max heap size. Do you see a case where a bigger default value could be a problem?
