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

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

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


From: GNU bug Tracking System
Subject: bug#52488: closed (Try basename of agrv0's realpath for .pdmp lookup in libexecdir)
Date: Thu, 23 Dec 2021 13:49:02 +0000

Your message dated Thu, 23 Dec 2021 08:48:18 -0500
with message-id <68f6a9d6-80c4-3a66-2381-9f3cb7a16299@cornell.edu>
and subject line Re: bug#52488: Try basename of agrv0's realpath for .pdmp 
lookup in libexecdir
has caused the debbugs.gnu.org bug report #52488,
regarding Try basename of agrv0's realpath for .pdmp lookup in libexecdir
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
52488: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=52488
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 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.

--- End Message ---
--- Begin Message --- Subject: Re: bug#52488: Try basename of agrv0's realpath for .pdmp lookup in libexecdir Date: Thu, 23 Dec 2021 08:48:18 -0500 User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0
On 12/19/2021 10:26 AM, Ken Brown wrote:
On 12/19/2021 7:57 AM, Lars Ingebrigtsen wrote:
Skimming this thread, it's not quite clear whether there's anything more
here to do here?

There's nothing more to do from my POV, but I don't know if Bhavin agrees.

I'm closing this now since Bhavin hasn't disagreed.

Ken


--- End Message ---

reply via email to

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