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

[Spencer Baugh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: 73318@debbugs.gnu.org,  larsi@gnus.org,  acorallo@gnu.org,
>>    schwab@linux-m68k.org,  shipmints@gmail.com
>> Date: Fri, 04 Oct 2024 09:22:08 -0400
>> 
>> > The specific issue with finding the pdumper file more reliably is
>> > solved in Emacs 30 in the way Andreas suggested, but it has no effect
>> > on the problem which you describe, with finding the preloaded *.eln
>> > files.
>> 
>> Ah, interesting.  So Emacs 30 falls back on looking up the pdmp in
>> PATH_EXEC, a path compiled into the Emacs binary.
>> 
>> Should we perhaps do the same for the native-lisp directory?
>
> We already do, sort of.  We just rely on the search for the pdumper
> file to supply us with the answer.  See below.
>
>> If we can't find it in other ways, look it up relative to a path
>> compiled into the Emacs binary?  I don't know if that should be
>> PATH_EXEC or some other path.
>> 
>> That would work on my system.  Then we wouldn't need to use
>> /proc/self/exe at all.
>> 
>> Might that be the best solution?
>
> 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?

So the two solutions that seem possible right now are:

A. If we fail to find an eln file relative to the Emacs executable, fall
   back to PATH_EXEC (or something similar)

B. Always look for eln files at a path relative to the pdmp, instead of
   relative to the Emacs executable.

>> >> >   . what if /proc/self/exe is unreadable? AFAIK, on some systems you
>> >> >     need special privileges to follow its symlink
>> >> >   . what if /proc/self/exe points to a file name that is a symlink, or
>> >> >     some of its leading directories are symlinks?
>> >> >   . what if Emacs is invoked via a script which is in the correct
>> >> >     installation directory, but the actual binary the script invokes
>> >> >     is not in the expected location relative to the native-lisp/
>> >> >     directory where we have the preloaded *.eln files?
>> >> >
>> >> > The existing code handles all these cases, and some others.  We could
>> >> > perhaps _add_ the use of /proc/self/exe to what we have, but we'd need
>> >> > to be sure that it doesn't break for the above situations.
>> >
>> > I'm still waiting for some answers to these.
>> 
>> If we use /proc/self/exe, I'm fine with it being a fallback if all other
>> mechanisms fail.  That should make these cases still work fine, right?
>
> To use /proc/self/exe as fallback, we need to somehow reject the Emacs
> "executable" found in your case.  Because otherwise fallbacks are only
> used if the previous attempts fail, and the attempt to find atgv[0]
> along PATH does not fail in your case, it just finds the "wrong" file.

True, so maybe /proc/self/exe is not a good solution.

>> > Why cannot you modify the script for all the commands to include the
>> > leading directories in executable-name?  That is all that is needed
>> > for Emacs to find its *.eln files.
>> 
>> See the motivation that I quoted above:
>> 
>>  For context, I believe the reason why we pass `-a` is to make the prog
>>  more identifiable when users try to find it in the output of
>>  `ps`. That still sounds like the right thing to do in the majority of
>>  the cases.
>> 
>> Including the leading directories would make them show up in the output
>> of "ps", which is uglier.
>
> "Uglier" is in the eyes of the beholder.  The important thing is that
> it solves the problem without any other changes, and will then use
> code which was tested and validated by many users.
>
>> I realize this might not seem like an important justification, but it
>> works for every other program we run, and has worked for decades.  And
>> other distributors might be doing this too, so I think it's reasonable
>> to make Emacs robust to this by having it fall back to looking up
>> native-lisp in something like PATH_EXEC.
>
> I disagree that this is reasonable, and what you suggest is not
> possible/practical anyway.
>
>> But now I think we maybe don't need to use /proc/self/exe at all, and
>> can just have Emacs fall back on something like PATH_EXEC when it fails
>> to find the native lisp files.
>
> 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.