emacs-devel
[Top][All Lists]
Advanced

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

Re: --with-native-compilation build failure on 32-bit systems


From: Andrea Corallo
Subject: Re: --with-native-compilation build failure on 32-bit systems
Date: Thu, 18 Aug 2022 16:42:24 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org
>> Date: Thu, 18 Aug 2022 14:50:23 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Andrea Corallo <akrl@sdf.org>
>> >> Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org
>> >> Date: Thu, 18 Aug 2022 14:09:45 +0000
>> >> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> >> From: Andrea Corallo <akrl@sdf.org>
>> >> >> Cc: larsi@gnus.org, jrm@ftfl.ca, emacs-devel@gnu.org, emacs@FreeBSD.org
>> >> >> Date: Thu, 18 Aug 2022 11:08:32 +0000
>> >> >> 
>> >> >> On 64bit I get:
>> >> >> 
>> >> >> emacs:0:Pure Lisp storage overflow (approx. 3366891 bytes needed)
>> >> >> 
>> >> >> On 32:
>> >> >> 
>> >> >> emacs:0:Pure Lisp storage overflow (approx. 2549794 bytes needed)
>> >> >
>> >> > That's soooo strange!  If I start Emacs under GDB and print the value
>> >> > of PURESIZE, I get 6000000 bytes in a 64-bit build and 4480000 bytes
>> >> > in a 32-bit build --with-wide-int.  What values do you see?
>> >> >
>> >> > Maybe the problem happens only in --without-x builds?
>> >> 
>> >> I get 2000000 on the 32bit build and 3333333 on 64 bit.  Both are indeed
>> >> --without-x.  According a to comment in puresize.h this has an effect.
>> >
>> > What is the value of SYSTEM_PURESIZE_EXTRA in both cases?
>> 
>> Zero in both cases.
>
> I'm confused.  puresize.h says
>
>   #define BASE_PURESIZE (2750000 + SYSTEM_PURESIZE_EXTRA + 
> SITELOAD_PURESIZE_EXTRA)
>   [...]
>   #define PURESIZE  (BASE_PURESIZE * PURESIZE_RATIO * PURESIZE_CHECKING_RATIO)
>
> So even if PURESIZE_RATIO and PURESIZE_CHECKING_RATIO are both 1, how
> come you get 2000000 in the 32-bit build, when SYSTEM_PURESIZE_EXTRA
> is zero?  I must be missing something.

It's 2000000 as my testbed for this bug as mentioned it is based on
aff5961274 (a master around the time the bug was reported), so before
your e46668847d.  Your commit changed the constant we add for computing
BASE_PURESIZE from 2000000 to 2750000.

This also indeed explains why Joseph reported the build to be again
working even without my fixes to the nativecomp side.

Thanks

  Andrea



reply via email to

[Prev in Thread] Current Thread [Next in Thread]