Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> * guix/build/utils.scm (wrap-program): Set the value of the -a option of
> `exec’ in the wrapper to ${0##*/} instead of $0, to use its base name instead
> of the complete file name.
>
> Fixes: <https://issues.guix.gnu.org/73405>
> Change-Id: Iec5984d4d934c8df88a90ff653947f7d07413ae4

I have a hacky extra wrap-program around Emacs (in a separate package so
I don’t have to rebuild Emacs), and this change (now on master after the
recent core-packages-team merge) seems to have broken it:

┌────
│ $ 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
└────

It appears Emacs does some dubious things in ‘find_emacs_executable’;
namely, if you execute Emacs without a slash in ‘argv[0]’, it “resolves”
the path by just searching PATH for ‘argv[0]’. This heuristic is used to
find the native-lisp directory, and it breaks when a wrapper like this
is not in the same directory as the Emacs executable.

I am not really advocating for reverting this. I don’t think Emacs
should assume ‘argv[0]’ is correlated to the executable file name. I
just want to write this down in proximity to the change that exposed it.
I will probably report to Emacs since the C is relatively new.

—Liam