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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 09 Aug 2025 15:00:02 +0300

tags 79064 wontfix
close 79064
thanks

> Cc: [email-masked]
> Date: Mon, 21 Jul 2025 14:38:55 +0300
> From: Eli Zaretskii <[email-masked]>
> 
> > 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.

No further comments, so I'm now closing this bug.