Subject: bug#78783: 30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work

From: Spencer Baugh <[email-masked]>
Date: Wed, 9 Jul 2025 13:43:11 -0400

On Wed, Jul 9, 2025 at 1:36 PM Eli Zaretskii <[email-masked]> wrote:
>
> > From: Spencer Baugh <[email-masked]>
> > Date: Wed, 9 Jul 2025 12:17:26 -0400
> > Cc: [email-masked], [email-masked], [email-masked]
> >
> > > > When I compile a .o on my machine and then copy it to a user machine and run it there, it is the same file,
> > > > because it has the same contents and the same name.
> > >
> > > You can only do that if the other machine has exactly the same
> > > architecture and the same versions of system libraries.  See bug#78907
> > > for what happens otherwise.
> >
> > Yes, of course.  But this is how package managers work: they provide
> > binaries that are compiled on one machine and then installed on many
> > user machines, and this works because they are careful to use binaries
> > on the same architecture and with the same system libraries.
>
> If the architecture is the same, you can take the *.eln files you
> compiled on your system and install them on the end-user's one.  So I
> don't see a problem to begin with -- you should be able to solve your
> problem with a local solution.

Not if those *.eln files were compiled before installing Emacs, e.g.
with emacs-lisp-native-compile as you suggested.

> > > If you are trying to argue that we should give up the strict testing
> > > which is precondition for loading a .eln file, then it's not going to
> > > happen, sorry.  Crashing an Emacs session due to some
> > > incompatibilities we avoid this way is a much higher price to pay than
> > > what you describe, even if there's no better solutions within the
> > > current restrictions.
> >
> > The strict testing done by comp-el-to-eln-rel-filename is deliberately
> > weakened for files under PATH_REL_LOADSEARCH or PATH_DUMPLOADSEARCH:
> > part of the filename is ignored and not checked.  I am simply
> > suggesting that we should do the same exact thing for files under
> > PATH_SITELOADSEARCH.
>
> I don't see the need.  The Emacs build doesn't compile any files
> inside directories on that path, so there's no reason for the upstream
> project to complicate the code on behalf of situations that don't
> happen when Emacs is built.  There should be no problem for you to do
> it with your local arrangements.

What local arrangement are you suggesting?  I can indeed locally patch
comp-el-to-eln-rel-filename to ignore part of the filename for files
under PATH_SITELOADSEARCH, and that's my current plan, if you think
this is reasonable.