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

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Correct, okay the warning should not be a problem (taking note into my
todo).

Do we really have installations with no source code?

> 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.

Yes it does that :) (I tipically use Emacs installed).

>> > 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?

When the file was preloaded when reviving from dump it is looked-up
using its filename, as you suggests includes the `comp-abi-hash' in it.

Thanks

  Andrea