GNU bug report logs -
#46495
28.0.50; [native-comp] Build fails for 32bit --with-wide-int
Previous Next
Full log
View this message in rfc822 format
> 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.