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

[Andrea Corallo <akrl@sdf.org>]

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: Wed, 17 Aug 2022 21:01:48 +0000
>> 
>> > So yeah I guess tomorrow I'll prepare the patch were we keep a list of
>> > loaded CU to fix-up.
>> 
>> Right I pushed the fix to scratch/better-cu-fixup so far as:
>> 
>> - I don't know if we want 1a637303b4 and 4bdda39f71 in master or 28.
>
> The problem doesn't exist on emacs-28, does it?

AFAIK we never got a report of it.

> I use a 32-bit build
> of that branch all the time, including Emacs 28.1 and the pretests of
> Emacs 28.2, and never had any problems.
>
> If the problem doesn't exist on the release branch, I'd prefer to
> leave it alone, as these changes are not entirely trivial, although
> look quite simple.

I agree.

>> - I suspect there's some good reason I'm not aware of why we don't
>>   eb539e92e9 at all (this is not necessary to fix the reported issue
>>   tho).
>
> Like I said earlier, I always thought that this problem doesn't affect
> the pdumper builds.  Perhaps that's not true with native-compilation?

Certainly native-compilation was relying more on the GC than the
standard build for the discussed mechanism, OTOH I'm not sure how
potentially having the GC not functional in temacs is a serious issue.

But is also worth considering that, given almost no-one is building with
unexec now days, if we don't monitor for purespace overflow in pdumper
we'll regularly overflow from time to time without noticing it.

Regards

  Andrea