GNU bug report logs -
#78783
30.1.50; AOT-compiling site-lisp during the Emacs build doesn't work
Previous Next
Full log
Message #43 received at 78783 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jul 9, 2025 at 1:36 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Date: Wed, 9 Jul 2025 12:17:26 -0400
> > Cc: acorallo <at> gnu.org, 78783 <at> debbugs.gnu.org, app-emacs-dev <at> janestreet.com
> >
> > > > 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.
This bug report was last modified 68 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.