GNU bug report logs - #52912
29.0.50; Left over files from native compilation

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Fri, 31 Dec 2021 05:22:02 UTC

Severity: normal

Merged with 48141

Found in versions 28.0.50, 29.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

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: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 52912 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, akrl <at> sdf.org
Subject: bug#52912: 29.0.50; Left over files from native compilation
Date: Sat, 22 Jan 2022 12:56:09 +0200
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: akrl <at> sdf.org,  52912 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca
> Date: Sat, 22 Jan 2022 11:50:18 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Yes.  Those which are without "native compiled elisp" are the ones
> > that got updated since the previous build.
> 
> Hm...  this was with a "make bootstrap", though.

Then perhaps the time stamp variation on your system sometimes makes
the *.eln files newer than the *.elc?

> > If you touch all the preloaded *.el files and rebuild, you will see
> > _no_ "native compiled elisp" at all, only *.elc files get loaded.
> 
> That's been a long-standing problem, though -- whenever subr.el is
> updated (or something), help-fns-test-lisp-defun fails.  (But I've never
> taken the time to find out why.)

No, I think it's a separate issue.  At least on my system, touching
all the preloaded *.el files would produce a coherent build with all
the *.eln files recompiled.




This bug report was last modified 3 years and 116 days ago.

Previous Next


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