GNU bug report logs -
#79064
native-lisp directory resolution shouldn’t depend on Emacs filename resolution via argv[0]
Previous Next
Full log
Message #13 received at control <at> debbugs.gnu.org (full text, mbox):
tags 79064 wontfix
close 79064
thanks
> Cc: 79064 <at> debbugs.gnu.org
> Date: Mon, 21 Jul 2025 14:38:55 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > 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.
No further comments, so I'm now closing this bug.
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.