[Top][All Lists]

[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 08:06:43 +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: 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.



reply via email to

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