Subject: Re: bug#63288: 30.0.50; Emacs 30 packages fail to build with native comp on some machines

From: Pip Cet <[email-masked]>
Date: Sun, 02 Feb 2025 09:34:34 +0000

<[email-masked]> writes:

> On 2025-01-29T19:46:04.000+01:00, Pip Cet <[email-masked]> wrote:
>> without going into too much detail, I think bytecomp.elc is not what it
>> should be.  Would it be possible for you to provide the 184350-byte
>> version you've seen in the broken build, and the (possibly 184350-byte)
>> version that produced a working Emacs?  The differences might be very
>> interesting.  Note that it is the .elc files that are interesting, not
>> their .el sources, and Emacs ignores the .elc extension when tab
>> completing by default.
>>
>> (Those files are long; if you cat them together and pipe through zstd
>> -22 --ultra --long, the result should be short enough to send).
>>
>> If you sill have time, warnings.elc may also be interesting.
>>
>> Thanks!
>>
>> Pip
>
> Here you are!

So I was in luck and the files were two copies of the "bad" files.
Unfortunately, while package.elc is clearly incorrect, it's less obvious
in these cases, because both versions seem correct: in bytecomp.elc, an
(inline ...) form is treated as progn in one build and inlined using
byte-optimize-inline-handler in the other.  I can reproduce that
difference by forcing byte-opt.el not to be compiled before bytecomp is.

Andrea, I'd like to carefully suggest that this is possibly bug#74771.
I still don't understand how reproducible this bug (bug#63288) is,
particularly without a 24-core CPU is, but my next suggestion would be
to disable nativecomp optimizations to see whether we're miscompiling
bytecomp.el.

But I'd like to make sure I'm not missing a more obvious explanation
here, so please let me know whether it's better to leave this bug to you
for now.

Thanks!

Pip