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

[Joseph Mingrone <jrm@ftfl.ca>]

On Thu, 2022-08-18 at 08:06, Andrea Corallo <akrl@sdf.org> wrote:

> 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.

FWIW, 32-bit builds started completing again (on FreeBSD 13.0) in the last week or so.

http://pkg.ftfl.ca/data/latest-per-pkg/emacs-devel/29.0.50.20220811%2C2/13i386-default.log