GNU bug report logs - #63288
30.0.50; Emacs 30 packages fail to build with native comp on some machines

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: pipcet <at> protonmail.com, acorallo <at> gnu.org, damien <at> merenne.me
Cc: 63288 <at> debbugs.gnu.org
Subject: bug#63288: 30.0.50; Emacs 30 packages fail to build with native comp on some machines
Date: Sat, 01 Mar 2025 14:09:07 +0200

Ping! Ping! Any further progress here?

> Cc: damien <at> merenne.me, 63288 <at> debbugs.gnu.org
> Date: Sat, 15 Feb 2025 13:20:52 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Ping! Can we please make some progress in this matter?
> 
> > Date: Sun, 02 Feb 2025 09:34:34 +0000
> > From: Pip Cet <pipcet <at> protonmail.com>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>, 63288 <at> debbugs.gnu.org
> > 
> > <damien <at> merenne.me> writes:
> > 
> > > On 2025-01-29T19:46:04.000+01:00, Pip Cet <pipcet <at> protonmail.com> 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
> > 
> > 
> 
> 
> 
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.