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

Previous Next

To reply to this bug, email your comments to 79064 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Liam Hupfer <liam <at> hpfr.net>
To: bug-gnu-emacs <at> gnu.org
Subject: native-lisp directory resolution shouldn’t
 depend on Emacs filename resolution via argv[0]
Date: Sun, 20 Jul 2025 23:30:44 -0500

[Message part 1 (text/plain, inline)]

Hi,

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.

Message #8 received at 79064 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Liam Hupfer <liam <at> hpfr.net>
Cc: 79064 <at> debbugs.gnu.org
Subject: Re: bug#79064: native-lisp directory resolution
 shouldn’t depend on Emacs filename resolution via
 argv[0]
Date: Mon, 21 Jul 2025 14:38:55 +0300

> From: Liam Hupfer <liam <at> hpfr.net>
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.