GNU bug report logs - #62317
28.2; This byte-compiled file behaves wrongly.

Previous Next

Package: emacs;

Reported by: Teika Kazura <teika <at> gmx.com>

Date: Tue, 21 Mar 2023 03:58:02 UTC

Severity: normal

Tags: patch, wontfix

Found in version 28.2

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Teika Kazura <teika <at> gmx.com>
To: 62317 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, akrl <at> sdf.org
Subject: bug#62317: bug #62317: 28.2; This byte-compiled file behaves wrongly.
Date: Thu, 30 Mar 2023 18:20:45 +0900 (JST)
Hi. I found a relation of this bug to native compilation, but there's a new, independent bug. Anyway remember the problem here is the pair of require - set-buffer, and I'm using 28.2. (I know it's not safe. :p)

What surprises is that `native-compile-async' and `batch-native-compile' generate differnt codes. To show it, use the same init.el and a.el above. Byte-compile first a.el, then init.el. Next native-compile init.el. Run emacs, and the above bug appears.

The difference is that (i) if you use native-compile-async, by removing one of init-<hash>.eln or init.elc, the bug disappears, even if the other remains. But (ii) if you use "$ emacs -Q -batch -f batch-native-compile *el", eln in fact does not matter; only the presence of init.elc screws things up.

# Who can expect this?

At the very least, native-compilation has too many undocumented aspects. If you want, I'll open a new bug for this discrepancy.

# It's off-topic for this bug, but for the above sample code, automatic, asynchronous generation of an eln file does not happen, unlike the case of my real init.el. I can't find the reason yet.

Regards,
Teika





This bug report was last modified 1 year and 249 days ago.

Previous Next


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