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

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

[Bhavin Gandhi]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3287 bytes --]

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

[Bhavin Gandhi]

On Wed, 15 Dec 2021 at 00:32, Bhavin Gandhi <bhavin7392@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.

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

[Ken Brown]

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

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

[Ken Brown]

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

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

[Glenn Morris]

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)

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

[Ken Brown]

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

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

[Ken Brown]

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

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

[Lars Ingebrigtsen]

Ken Brown <kbrown@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

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

[Ken Brown]

On 12/19/2021 7:57 AM, Lars Ingebrigtsen wrote:
> Ken Brown <kbrown@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

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

[Ken Brown]

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

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

[Bhavin Gandhi]

Hello Lars and Ken,

On Sun, 19 Dec 2021 at 20:56, Ken Brown <kbrown@cornell.edu> wrote:
>
> On 12/19/2021 7:57 AM, Lars Ingebrigtsen wrote:
> > Ken Brown <kbrown@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#52488: Try basename of agrv0's realpath for .pdmp lookup in libexecdir

[Bhavin Gandhi]

On Wed, 15 Dec 2021 at 01:12, Eli Zaretskii <eliz@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@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!

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

[Eli Zaretskii]

> From: Bhavin Gandhi <bhavin7392@gmail.com>
> Date: Wed, 15 Dec 2021 23:54:23 +0530
> Cc: 52488@debbugs.gnu.org
> 
> On Wed, 15 Dec 2021 at 01:12, Eli Zaretskii <eliz@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?

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

[Eli Zaretskii]

> From: Bhavin Gandhi <bhavin7392@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?