Subject: Re: bug#73318: 31.0.50; with-native-compilation=aot breaks exec -a emacs

From: Eli Zaretskii <[email-masked]>
Date: Fri, 04 Oct 2024 22:09:50 +0300

> From: Spencer Baugh <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked],
>    [email-masked],  [email-masked]
> Date: Fri, 04 Oct 2024 12:51:59 -0400
> 
> > It isn't that easy.  We need to support 2 possible locations for the
> > preloaded *.eln files: in the source tree and in the installation
> > tree.  You now want us to look in yet a third place.  Take a look at
> > dump_do_dump_relocation where we look for the *.eln files.  What you
> > suggest is to add a third place to that code.
> 
> Yes.  I suggest that if installation_state == INSTALLED, and we fail to
> find an eln file in emacs_execdir, we fall back to look in PATH_EXEC (or
> some other path compiled into the Emacs binary).
> 
> But it occurs to me that there's another possible solution.  We already
> have a robust way to find the pdump.  My Emacs finds the pdump and loads
> it just fine.  Maybe we could look for the eln files relative to the
> pdump?

That means to throw away a lot of code in emacs.c which we use now and
was tested for several Emacs releases.  No, thanks, not for this
obscure scenario.

I still don't understand why you insist on not changing your script to
include the leading directories in argv[0].  It makes absolutely no
sense to me to invent new code in such a place, when the alternative
is so easy and reliable.

> > See above.  If you insist to go this much more complicated way, we'll
> > need to modify the code in dump_do_dump_relocation to use PATH_EXEC,
> > and deal with possible false positives.
> 
> Yes, I am willing to put in the effort to do that.

Makes no sense to me, so I urge you to reconsider.  You are
destabilizing Emacs for the benefit of an obscure use pattern that is
easy to fix without any changes in Emacs.