bug#50230: Endian problem with native compilation

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 01 Sep 2021 19:05:56 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: schwab@linux-m68k.org, 50230@debbugs.gnu.org
> 
> > From: Andrea Corallo <akrl@sdf.org>
> > Cc: schwab@linux-m68k.org, 50230@debbugs.gnu.org
> > Date: Wed, 01 Sep 2021 15:13:54 +0000
> > 
> > This is changing the cast functions we synthesize and use in all the
> > code we generate, so yes it is potentially destabilizing.
> > 
> > That said the generated code looks correct to me (and considerably
> > cleaner).  Also, given these functions are really the foundation of a
> > lot of other code we generate I guess would be unlikely to have these
> > wrong but still have the testsuite passing clean and Emacs booting up
> > correctly.  Call me optimistic but I'd be pretty confident with this
> > change...
> 
> OK, thanks.  We'll see how it goes (after you find the problem with
> endianness and fix it).

I've noticed that building Emacs --with-native-compilation after this
change still uses the same subdirectory of native-lisp/ for the
preloaded files, and doesn't recompile *.eln files that were
native-compiled before the change (unless the corresponding *.el files
were updated in the meantime).  Shouldn't we recompile all the *.eln
files after this change?

I don't know if Andreas did recompile all of them, but if not, perhaps
that's one reason why the change didn't fix Emacs on big-endian
systems?