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

From: Spencer Baugh <[email-masked]>
Date: Mon, 07 Oct 2024 10:18:37 -0400

Eli Zaretskii <[email-masked]> writes:

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

OK, then perhaps just falling back on finding it relative to the pdump.

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

I would change the script if I could, but I can't: It's already been
copied into thousands of users' home directories.  It's such a tiny
wrapper (it just does "exec -a program /path/to/program") that it has
never needed to be modified for any program before this.

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