Subject: bug#79064: native-lisp directory resolution shouldn’t depend on Emacs filename resolution via argv[0]

From: Eli Zaretskii <[email-masked]>
Date: Mon, 21 Jul 2025 14:38:55 +0300

> From: Liam Hupfer <[email-masked]>
> Date: Sun, 20 Jul 2025 23:30:44 -0500
> 
> In find_emacs_executable, Emacs searches for its own executable based on
> argv[0]. If argv[0] has a slash in it, it assumes it is the path to the
> Emacs binary and makes it absolute. If not, it searches PATH for
> argv[0]. The resulting absolute filename is used to find the dump file,
> the native-lisp directory, and in kill-emacs to support restarting.
> 
> In general, argv[0] can’t be relied upon to find the executable for a
> process. It’s probably the best approach for the restarting case, and
> there it’s not a big deal to just fail to restart if argv[0] is
> misleading. But application startup can’t depend on it resolving
> correctly. load_pdump has a hardcoded fallback based on PATH_EXEC which
> is built into the executable, but currently native-lisp resolution does
> not. Can we set up something similar there?
> 
> Thanks!
> 
> —Liam
> 
> 
> Context
> ═══════
> 
> This became a problem for me when I wrapped Emacs with a shell script
> called “emacs” which sets some environment variables and calls Emacs
> with
> 
> ┌────
> │ exec -a emacs "$emacs_path" "$@"
> └────
> 
> find_emacs_executable returns the path to the wrapper if it is on PATH.
> If it isn’t in the same directory as the Emacs binary,
> dump_do_dump_relocation will fail when it can’t find the native-lisp
> directory:
> 
> ┌────
> │ $ emacs
> │ Error using execdir /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/:
> │ emacs: /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/../native-lisp/30.1.90-f736b5c5/preloaded/window.eln: cannot open shared object file: No such file or directory
> └────
> 
> Wrappers like this are typical with package managers like Nix and Guix
> running on other Linux distributions, where it can be necessary to set
> variables like GDK_PIXBUF_MODULE_FILE and GIO_EXTRA_MODULES to ensure
> GTK applications like Emacs don’t use incompatible resources from the
> host GTK version.
> 
> It’s possible to work around this by not using ‘exec -a’ this way. But
> I’m opening the bug because Emacs should handle unpredictable argv[0]
> values robustly, regardless of my particular context.

I'm extremely reluctant to make significant changes in that tricky and
complex code, just to support this use case, which has other
solutions.  It took us quite a few iterations to get to where we are
now, and the result supports several important situations with
symlinks to the Emacs binary or to its directories, moving the entire
Emacs installation tree, etc.  It also supports several operating
systems with vast;y different peculiarities.

It is true that argv[0] is not 100% reliable, but we also don't rely
just on it, we use several heuristics and fallbacks.

(To answer your specific question: we don't use something similar to
PATH_EXEC because the 30.1.90-f736b5c5 part of the directory name is
computed dynamically during the late stages of the build, when the C
sources were already compiled and linked.)

>From where I stand, the expectation that Emacs startup code must
support arbitrary tweaks in the "usual" installation scenario is
unjustified.  Package managers are respectfully requested to tweak
their scripts to adapt to what Emacs requires, supports, and expects
in this regard, because they (the package managers) are those which
make these modifications in the "usual" installation directory
structure in the first place.

Sorry.