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

Previous Next

Full log

View this message in rfc822 format

From: Liam Hupfer <liam <at> hpfr.net>
To: 79064 <at> debbugs.gnu.org
Subject: bug#79064: 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.

Previous Next

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