GNU bug report logs -
#73318
31.0.50; with-native-compilation=aot breaks exec -a emacs
Previous Next
Full log
Message #59 received at 73318 <at> debbugs.gnu.org (full text, mbox):
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 73318 <at> debbugs.gnu.org, larsi <at> gnus.org, acorallo <at> gnu.org,
> schwab <at> linux-m68k.org, shipmints <at> 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. Currently, we infer
where the *.eln files are by looking at the file name of the Emacs
executable file. And your script violates this protocol by removing
the leading directories from argv[0] and placing Emacs in a directory
not on PATH.
> >> > . 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.
> > 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.
This bug report was last modified 248 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.