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

Previous Next

Package: emacs;

Reported by: Brian Leung <leungbk <at> posteo.net>

Date: Fri, 5 May 2023 04:00:02 UTC

Severity: normal

Found in version 30.0.50

Done: Pip Cet <pipcet <at> protonmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>, acorallo <at> gnu.org
Cc: damien <at> merenne.me, 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, 15 Feb 2025 13:20:52 +0200
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
> 
> 




This bug report was last modified 132 days ago.

Previous Next


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