bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52488: Try basename of agrv0's realpath for .pdmp lookup in libexecd


From: Bhavin Gandhi
Subject: bug#52488: Try basename of agrv0's realpath for .pdmp lookup in libexecdir
Date: Wed, 15 Dec 2021 00:31:02 +0530

Referring to this message https://debbugs.gnu.org/52376#86 it is advised
to keep the .pdmp file in the libexecdir instead of putting it along
side the Emacs executable.

Currently the load_pdump from emacs.c first looks for a .pdmp file in
the same directory where Emacs executable is present. While doing that
it calls load_pdump_find_executable, which tries to resolve symlinks and
finds the real name of the binary being invoked. Then this name is used
to find the .pdmp file.

  /* If the executable name contains a slash, we have some kind of
     path already, so just resolve symlinks and return the result.  */

 /* People put on PATH a symlink to the real Emacs
    executable, with all the auxiliary files where the real
    executable lives.  Support that.  */


IIUC when searching for the .pdmp file in the libexecdir (path_exec), it
uses argv0 and does not find the actual binary name by resolving
symlinks.

      /* Finally, look for basename(argv0)+".pdmp" in PATH_EXEC.
This way, they can rename both the executable and its pdump
file in PATH_EXEC, and have several Emacs configurations in
the same versioned libexec subdirectory.  */


Why do you want that?

As the comment from load_pdump_find_executable explains, there are
setups where the /usr/bin/emacs is a symlink managed by something like
alternatives. This symlink eventually points to an Emacs binary like
emacs-28.0.90. These kind of setups are used to have installation of
multiple versions of Emacs on the same system.

Supporting resolution of these symlinks while searching for a .pdmp file
will make it possible to put the .pdmp files in libexecdir instead of
putting those in the /usr/bin/. I think this should be in addition to
the possibilities tried currently.

> Why don't you configure each Emacs build with a different libexecdir
> instead?

Sure, but there are some common files in that directory like hexl,
movemail, etc, which package maintainers have put into a common package
like emacs-common.

How to reproduce?

Install Emacs using make install on your system with correct libexecdir
(it is /usr/libexec/ in my case). This will create a symlink
/usr/bin/emacs which points to /usr/bin/emacs-28.0.90.

Now rename the .pdmp file with:

$ sudo mv /usr/libexec/emacs/28.0.90/x86_64-linux-gnu/{emacs.pdmp,emacs-28.0.90.pdmp}

Now start Emacs:

$ emacs -Q
Loading loadup.el (source)...
Dump mode: nil
Using load-path (/usr/share/emacs/28.0.90/lisp /usr/share/emacs/28.0.90/lisp/emacs-lisp /usr/share/emacs/28.0.90/lisp/progmodes /usr/share/emacs/28.0.90/lisp/language /usr/share/emacs/28.0.90/lisp/international /usr/share/emacs/28.0.90/lisp/textmodes /usr/share/emacs/28.0.90/lisp/vc)
Loading emacs-lisp/byte-run...
Symbol's function definition is void: file-name-sans-extension

Note that the Emacs build above is created with
--with-native-compilation.

I'm not sure if this bug's severity is wishlist or not, so I'm not setting
it right now.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]