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

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: andrewjmoreton@gmail.com, 46495@debbugs.gnu.org
> Date: Thu, 01 Apr 2021 07:07:53 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andrea Corallo <akrl@sdf.org>
> >> Cc: andrewjmoreton@gmail.com, 46495@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?