GNU bug report logs -
#52488
Try basename of agrv0's realpath for .pdmp lookup in libexecdir
Previous Next
Reported by: Bhavin Gandhi <bhavin7392 <at> gmail.com>
Date: Tue, 14 Dec 2021 19:02:02 UTC
Severity: normal
Tags: moreinfo
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 52488 in the body.
You can then email your comments to 52488 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Tue, 14 Dec 2021 19:02:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Bhavin Gandhi <bhavin7392 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 14 Dec 2021 19:02:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Tue, 14 Dec 2021 19:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 52488 <at> debbugs.gnu.org (full text, mbox):
On Wed, 15 Dec 2021 at 00:32, Bhavin Gandhi <bhavin7392 <at> gmail.com> wrote:
>
> 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.
Consider a scenario where /usr/bin/emacs-nox is a symlink to
emacs-28.0.90-nox. And we have emacs-nox.pdmp in libexecdir. This will
work with current implementation. But if Emacs is invoked directly as
emacs-28.0.90-nox, then it will fail.
> > 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.
This part of the message has nothing to do with the current bug report,
it is creating confusion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Tue, 14 Dec 2021 19:33:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 52488 <at> debbugs.gnu.org (full text, mbox):
On 12/14/2021 2:01 PM, Bhavin Gandhi wrote:
> 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.
This is exactly the setup that I use on Cygwin, as I alluded to in my message to
the other bug report. But I didn't mention there that I use symlinks managed by
alternatives.
> 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.
Yes. It's precisely because the symlinks aren't resolved that I've been putting
the .pdmp files in /usr/bin, alongside the emacs executables.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Tue, 14 Dec 2021 19:43:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 52488 <at> debbugs.gnu.org (full text, mbox):
> From: Bhavin Gandhi <bhavin7392 <at> gmail.com>
> Date: Wed, 15 Dec 2021 00:31:02 +0530
>
> 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?
Why do we want what?
> 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.
Patches to support that are welcome, I think. We support several
tricks people play with placing the binaries and the auxiliary files,
but there could well be other possibilities.
However, in general, keeping the .pdmp file in the same directory as
the binary is not recommended, AFAIU, as that file is not an
executable program. That path in the code exists mainly for running
Emacs uninstalled, from the build tree.
> > 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.
And you cannot use symlinks for those files, whose target is in the
common directory?
> $ 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
Andrea, can you please look into this error? Emacs is supposed to
load *.elc files in this case, and then start normally. Which code
tries to call file-name-sans-extension so early?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Wed, 15 Dec 2021 17:57:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 52488 <at> debbugs.gnu.org (full text, mbox):
On 12/14/2021 2:32 PM, Ken Brown wrote:
> On 12/14/2021 2:01 PM, Bhavin Gandhi wrote:
>> 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.
>
> This is exactly the setup that I use on Cygwin, as I alluded to in my message to
> the other bug report. But I didn't mention there that I use symlinks managed by
> alternatives.
>
>> 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.
>
> Yes. It's precisely because the symlinks aren't resolved that I've been putting
> the .pdmp files in /usr/bin, alongside the emacs executables.
On further reflection, I don't think the problem is symlink resolution for the
.pdmp file. I think the problem is that load_pdmp doesn't look in libexecdir
for a .pdmp file whose name matches the name of the emacs executable. For
example, suppose I have a symlink /usr/bin/emacs that resolves to
/usr/bin/emacs-nox.exe. Then load_pdmp looks for /usr/bin/emacs-nox.pdmp, but
it doesn't look for /usr/libexec/emacs/28.0.90/x86_64-pc-cygwin/emacs-nox.pdmp.
I'm working on a patch to fix this.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Wed, 15 Dec 2021 18:20:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 52488 <at> debbugs.gnu.org (full text, mbox):
Ken Brown wrote:
> I think the problem is that load_pdmp doesn't look in libexecdir for a
> .pdmp file whose name matches the name of the emacs executable. For
> example, suppose I have a symlink /usr/bin/emacs that resolves to
> /usr/bin/emacs-nox.exe. Then load_pdmp looks for
> /usr/bin/emacs-nox.pdmp, but it doesn't look for
> /usr/libexec/emacs/28.0.90/x86_64-pc-cygwin/emacs-nox.pdmp.
Note that in Emacs 29 it uses the fingerprint in the pdmp name,
so that issue should not occur.
(cf https://debbugs.gnu.org/43050)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Wed, 15 Dec 2021 18:26:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 52488 <at> debbugs.gnu.org (full text, mbox):
On Wed, 15 Dec 2021 at 01:12, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > Why do you want that?
>
> Why do we want what?
Why do I want to have what this bug's title says, I was writing in a
question / answer form.
> Patches to support that are welcome, I think. We support several
> tricks people play with placing the binaries and the auxiliary files,
> but there could well be other possibilities.
>
> However, in general, keeping the .pdmp file in the same directory as
> the binary is not recommended, AFAIU, as that file is not an
> executable program. That path in the code exists mainly for running
> Emacs uninstalled, from the build tree.
That's what I felt when I chose this way of putting a .pdmp file alongside
the Emacs binary. Me from past was naive enough to not ask about it here
or explore more about it.
On Wed, 15 Dec 2021 at 23:26, Ken Brown <kbrown <at> cornell.edu> wrote:
> On further reflection, I don't think the problem is symlink resolution for the
> .pdmp file. I think the problem is that load_pdmp doesn't look in libexecdir
> for a .pdmp file whose name matches the name of the emacs executable. For
> example, suppose I have a symlink /usr/bin/emacs that resolves to
> /usr/bin/emacs-nox.exe. Then load_pdmp looks for /usr/bin/emacs-nox.pdmp, but
> it doesn't look for /usr/libexec/emacs/28.0.90/x86_64-pc-cygwin/emacs-nox.pdmp.
Indeed Ken, my initial message was trying to convey the same. It could
have been more clear (I should not draft bug reports just before
sleeping :P).
> I'm working on a patch to fix this.
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Wed, 15 Dec 2021 18:54:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 52488 <at> debbugs.gnu.org (full text, mbox):
On 12/15/2021 1:19 PM, Glenn Morris wrote:
> Ken Brown wrote:
>
>> I think the problem is that load_pdmp doesn't look in libexecdir for a
>> .pdmp file whose name matches the name of the emacs executable. For
>> example, suppose I have a symlink /usr/bin/emacs that resolves to
>> /usr/bin/emacs-nox.exe. Then load_pdmp looks for
>> /usr/bin/emacs-nox.pdmp, but it doesn't look for
>> /usr/libexec/emacs/28.0.90/x86_64-pc-cygwin/emacs-nox.pdmp.
>
> Note that in Emacs 29 it uses the fingerprint in the pdmp name,
> so that issue should not occur.
>
> (cf https://debbugs.gnu.org/43050)
Thanks! I missed that.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Wed, 15 Dec 2021 19:34:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 52488 <at> debbugs.gnu.org (full text, mbox):
> From: Bhavin Gandhi <bhavin7392 <at> gmail.com>
> Date: Wed, 15 Dec 2021 23:54:23 +0530
> Cc: 52488 <at> debbugs.gnu.org
>
> On Wed, 15 Dec 2021 at 01:12, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > Why do you want that?
> >
> > Why do we want what?
>
> Why do I want to have what this bug's title says, I was writing in a
> question / answer form.
Doesn't the comment there explain that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Wed, 15 Dec 2021 22:09:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 52488 <at> debbugs.gnu.org (full text, mbox):
On 12/15/2021 1:53 PM, Ken Brown wrote:
> On 12/15/2021 1:19 PM, Glenn Morris wrote:
>> Ken Brown wrote:
>>
>>> I think the problem is that load_pdmp doesn't look in libexecdir for a
>>> .pdmp file whose name matches the name of the emacs executable. For
>>> example, suppose I have a symlink /usr/bin/emacs that resolves to
>>> /usr/bin/emacs-nox.exe. Then load_pdmp looks for
>>> /usr/bin/emacs-nox.pdmp, but it doesn't look for
>>> /usr/libexec/emacs/28.0.90/x86_64-pc-cygwin/emacs-nox.pdmp.
>>
>> Note that in Emacs 29 it uses the fingerprint in the pdmp name,
>> so that issue should not occur.
>>
>> (cf https://debbugs.gnu.org/43050)
>
> Thanks! I missed that.
FWIW, the commit in which you did this (e81f1faca4) applies to the emacs-28
branch and allows me to build emacs-28 for the Cygwin distro the way I want,
with all .pdmp files under /usr/libexec. There's no need to rename any .pdmp
files or to use symlinks for them.
Thanks again.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Sun, 19 Dec 2021 12:58:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 52488 <at> debbugs.gnu.org (full text, mbox):
Ken Brown <kbrown <at> cornell.edu> writes:
> FWIW, the commit in which you did this (e81f1faca4) applies to the
> emacs-28 branch and allows me to build emacs-28 for the Cygwin distro
> the way I want, with all .pdmp files under /usr/libexec. There's no
> need to rename any .pdmp files or to use symlinks for them.
Skimming this thread, it's not quite clear whether there's anything more
here to do here?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 19 Dec 2021 12:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Sun, 19 Dec 2021 15:27:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 52488 <at> debbugs.gnu.org (full text, mbox):
On 12/19/2021 7:57 AM, Lars Ingebrigtsen wrote:
> Ken Brown <kbrown <at> cornell.edu> writes:
>
>> FWIW, the commit in which you did this (e81f1faca4) applies to the
>> emacs-28 branch and allows me to build emacs-28 for the Cygwin distro
>> the way I want, with all .pdmp files under /usr/libexec. There's no
>> need to rename any .pdmp files or to use symlinks for them.
>
> 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.
Ken
Reply sent
to
Ken Brown <kbrown <at> cornell.edu>
:
You have taken responsibility.
(Thu, 23 Dec 2021 13:49:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Bhavin Gandhi <bhavin7392 <at> gmail.com>
:
bug acknowledged by developer.
(Thu, 23 Dec 2021 13:49:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 52488-done <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#52488
; Package
emacs
.
(Thu, 23 Dec 2021 13:51:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 52488 <at> debbugs.gnu.org (full text, mbox):
Hello Lars and Ken,
On Sun, 19 Dec 2021 at 20:56, Ken Brown <kbrown <at> cornell.edu> wrote:
>
> On 12/19/2021 7:57 AM, Lars Ingebrigtsen wrote:
> > Ken Brown <kbrown <at> cornell.edu> writes:
> >
> >> FWIW, the commit in which you did this (e81f1faca4) applies to the
> >> emacs-28 branch and allows me to build emacs-28 for the Cygwin distro
> >> the way I want, with all .pdmp files under /usr/libexec. There's no
> >> need to rename any .pdmp files or to use symlinks for them.
> >
> > 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.
Yes, IIUC this issue won't exist in Emacs 29.1. And we can use the
patch like Ken said.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 21 Jan 2022 12:24:09 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 307 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.