GNU bug report logs -
#73416
[PATCH core-updates] build: Set $0 to basename of command in `wrap-program'.
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Maxim Cournoyer <maxim.cournoyer <at> 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
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.