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?