GNU bug report logs - #46495
28.0.50; [native-comp] Build fails for 32bit --with-wide-int

Previous Next

Package: emacs;

Reported by: Andy Moreton <andrewjmoreton <at> gmail.com>

Date: Sat, 13 Feb 2021 17:58:02 UTC

Severity: normal

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Forwarded to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: andrewjmoreton <at> gmail.com, 46495 <at> debbugs.gnu.org
Subject: bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int
Date: Thu, 01 Apr 2021 10:42:59 +0300
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: andrewjmoreton <at> gmail.com, 46495 <at> debbugs.gnu.org
> Date: Thu, 01 Apr 2021 07:07:53 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Andrea Corallo <akrl <at> sdf.org>
> >> Cc: andrewjmoreton <at> gmail.com, 46495 <at> debbugs.gnu.org
> >> Date: Wed, 31 Mar 2021 19:43:17 +0000
> >> 
> >> > So with these 3 files in that directory, which one will be loaded by
> >> > Emacs, and how will Emacs know which to load?
> >> 
> >> Emacs will scan and hash the source file and load the correct one if
> >> present.
> >
> > And if the source file isn't available?
> 
> No eln will be loaded.

Ouch!  That's a general issue, then, not just when there are multiple
copies of *.eln for the same .el file, right?  IOW, if Emacs is
installed such that the *.el files are not available, it will not load
the *.eln files, only the *.elc files.  I think we should at least
produce a run-time warning about that.

If the .el file is available, but was compressed, will Emacs
scan it after uncompressing to verify the signature?  This is the
usual way Emacs is installed: we compress all the *.el files.

> > In any case, AFAIU I can safely delete the 2 older *.eln files because
> > they will never be used, right?
> 
> Correct, unless you have another binary that is using one of these eln
> as preloaded, indeed this should not be the case as comp.el is not
> preloaded.

But even if the file is preloaded, the fact that it is in the same
hashed subdirectory of native-lisp/ means it can be used with any
binary whose ABI is compatible.  Right?  Or are you saying that the
source-content hash of the .eln file is recorded in the .pdmp file?




This bug report was last modified 4 years and 43 days ago.

Previous Next


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