[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Emacs 30.1 fails to build on 32-bit archs, "Pure Lisp storage overflow"



Eli Zaretskii <eliz@gnu.org> writes:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: debian-emacsen@lists.debian.org
>> Date: Mon, 24 Feb 2025 20:02:58 +0800
>> 
>> 
>> On Mon 24 Feb 2025 at 07:42pm +08, Sean Whitton wrote:
>> 
>> > The new Emacs 30.1 fails to build on all of Debian's 32-bit release
>> > architectures, Intel and Arm.
>> >
>> > The failures look a little different in each case but in all three the
>> > string "Pure Lisp storage overflow" appears near the end of the log:
>> >
>> > armel:
>> > https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armel&ver=1%3A30.1%2B1-1&stamp=1740392779&raw=0
>> > armhf:
>> > https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0
>> > i386:
>> > https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0
>> 
>> Xiyue pointed me to #75907 -- thank you.
>> 
>> I can boost the BASE_PURESIZE just on Debian's builds but does it make
>> sense that we're hitting it sooner on 32-bit archs?
>
> The actual use of pure space depends on the length of the file names
> involved in the build, so if you build in a deeper directory, it could
> overflow.
>
> Also, are you building the original release tarballs, and only with
> "configure && make -jN", or are you building using some different
> procedure?  That could also explain the overflow.
>
> By how much do you need to enlarge to make the builds succeed?
>

FTR in the log of Debian armhf buildd[1] there is a line says:

,----
| emacs:0:Pure Lisp storage overflow (approx. 4546239 bytes needed)
`----

I tested that increasing the base value to 4500000 worked on i386 (patch
attached).  Also tested that 4M was not large enough.  Sean is also
testing 45 * 1024 * 1024 on 32-bit arm* buildds.

Though 4.5M is probably sufficient for now, I wonder whether it's
acceptable to further increase this to 5000000 to be more future proof?

On the other hand, I see there are threads on emacs-devel talking about
removing pure space.  Is that referring to this pure lisp storage?

[1] https://buildd.debian.org/status/fetch.php?pkg=emacs&arch=armhf&ver=1%3A30.1%2B1-1&stamp=1740392697&raw=0

-- 
Regards,
Xiyue Deng
From 753364b972cb2c9a32f05fc1ce639c981d5f8d04 Mon Sep 17 00:00:00 2001
From: Xiyue Deng <manphiz@gmail.com>
Date: Mon, 24 Feb 2025 13:45:04 -0800
Subject: [PATCH] Further increase BASE_PURESIZE for 32-bit archs

---
 src/puresize.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/puresize.h b/src/puresize.h
index f2576666a66..be727ba68cd 100644
--- a/src/puresize.h
+++ b/src/puresize.h
@@ -47,7 +47,7 @@ #define SITELOAD_PURESIZE_EXTRA 0
 #endif
 
 #ifndef BASE_PURESIZE
-#define BASE_PURESIZE (3400000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA)
+#define BASE_PURESIZE (4500000 + SYSTEM_PURESIZE_EXTRA + SITELOAD_PURESIZE_EXTRA)
 #endif
 
 /* Increase BASE_PURESIZE by a ratio depending on the machine's word size.  */
-- 
2.47.2

Attachment: signature.asc
Description: PGP signature


Reply to: