Re: Heap space when building SBCL packages
Guillaume Le Vaillant writes: > I pushed the fix as 47a2306415cf19270cb398590be3d95a92a0e73b. Thanks a lot - this works just fine! Cheers, Konrad.
Re: Heap space when building SBCL packages
Konrad Hinsen skribis: > Pierre Neidhardt writes: > >> Thanks for investigating this! >> Can you send a patch? Or maybe Guillaume? > > Not me, sorry. I haven't figured out yet how the asdf-build-system > works. Nor build systems in general. > > Cheers, > Konrad I pushed the fix as 47a2306415cf19270cb398590be3d95a92a0e73b. signature.asc Description: PGP signature
Re: Heap space when building SBCL packages
Pierre Neidhardt writes: > Thanks for investigating this! > Can you send a patch? Or maybe Guillaume? Not me, sorry. I haven't figured out yet how the asdf-build-system works. Nor build systems in general. Cheers, Konrad
Re: Heap space when building SBCL packages
Pierre Neidhardt writes: > You could also try playing with the > `--dynamic-space-size` command line flag, e.g. > > sbcl --dynamic-space-size 2048 ... That was a good idea. It turns out that 1024 is just a bit too low to do program-op, though load-system works. With 1280 I can do program-op on numcl. So it looks like SBCL 2.0.2 just needs a bit of extra memory compared to older versions. Guillaume's suggestion of increasing the limit should thus be sufficient. Cheers, Konrad.
Re: Heap space when building SBCL packages
You could also try playing with the `--dynamic-space-size` command line flag, e.g. sbcl --dynamic-space-size 2048 ... -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Heap space when building SBCL packages
Hi Pierre, >> 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. Worth testing, if only to have a non-Guix way to illustrate the issue for reporting upstream if necessary. Is there a way to get the exact ASD file plus command line that is used by the build system? >> 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? Building sbcl-numcl works fine with 1.5 and 2.0. It's only with 2.0.2 that there is this heap issue. > Maybe report this issue to the SBCL issue tracker, they will probably > know what's going on. If it's not a Guix issue, then yes, that's the way to proceed. Cheers, Konrad.
Re: Heap space when building SBCL packages
Pierre Neidhardt 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?
Re: Heap space when building SBCL packages
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! -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Heap space when building SBCL packages
Hi Guix, 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. 2. Building binaries with SBCL takes more heap space than merely loading a system from source via ASDF. 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? Cheers, Konrad.
