Re: Finding the dump (redux)

[Eli Zaretskii]

> From: Ali Bahrami <ali_gnu2@emvision.com>
> Date: Thu, 15 Apr 2021 13:38:37 -0600
> 
>       % cd /usr/bin
>       % ls -alFh emacs*
>       lrwxrwxrwx   1 root   root     9 Apr 14 22:15 emacs -> emacs-gtk*
>       -r-xr-xr-x   2 root   bin  7.05M Apr 14 22:15 emacs-gtk*
>       -r-xr-xr-x   2 root   bin  7.05M Apr 14 22:15 emacs-gtk-27.2*
>       -r-xr-xr-x   2 root   bin  6.09M Apr 14 22:15 emacs-nox*
>       -r-xr-xr-x   2 root   bin  6.09M Apr 14 22:15 emacs-nox-27.2*
>       -r-xr-xr-x   2 root   bin  7.07M Apr 14 22:15 emacs-x*
>       -r-xr-xr-x   2 root   bin  7.07M Apr 14 22:15 emacs-x-27.2*
>       -r-xr-xr-x   1 root   bin    47K Apr 14 22:15 emacsclient*
> 
> And the pdmp files are similarly named, to match the
> emacs executables:
> 
>       % cd /usr/lib/emacs/27.2/x86_64-pc-solaris2.11
>       % ls -alhF *.pdmp
>       -r--r--r--   2 root   bin  10.2M Apr 14 22:15 emacs-gtk-27.2.pdmp
>       -r--r--r--   2 root   bin  10.2M Apr 14 22:15 emacs-gtk.pdmp
>       -r--r--r--   2 root   bin  9.64M Apr 14 22:15 emacs-nox-27.2.pdmp
>       -r--r--r--   2 root   bin  9.64M Apr 14 22:15 emacs-nox.pdmp
>       -r--r--r--   2 root   bin  10.1M Apr 14 22:15 emacs-x-27.2.pdmp
>       -r--r--r--   2 root   bin  10.1M Apr 14 22:15 emacs-x.pdmp
> 
> As noted, the default is emacs-gtk, but I can change that:
> 
>       # pkg set-mediator -I emacs-x emacs
>       <...pkg output elided...>
>       # ls -alFh /usr/bin/emacs
>       rwxrwxrwx   1 root  root   7 Apr 15 11:47 /usr/bin/emacs -> emacs-x*
> 
> Like a lot of GNU/Linux distributions, we used to use a
> shell script for this, but we moved to the mediator years
> ago. With the new emacs, this works well for the explicitly
> named versions (emacs-gtk, emacs-nox, and emacs-x). But, when
> run via the 'emacs' symlink (the usual case), the binary is
> unable to find its pdmp file. It still runs, but ends up
> loading all the separate elc files, which is undesirable.
> 
> I can solve this without changing emacs, superficially, by just
> adding a corresponding mediator symlink for emacs.pdmp in the
> PATH_EXEC directory. But then, if an end user were to make their
> own symlink to one of these emacs variants, they'll still face
> this problem:
> 
>       % ln -s /usr/bin/emacs-gtk ~/bin/myemacs

Why can't you put the *.pdmp files in the same directory where you
keep the emacs-* executables (/usr/bin, AFAIU)?  That is already
supported by the current code, I think.

> Sure, that user could specify the pdmp file on the command
> line, or wrap it in a shell script, but for default behavior,
> I don't think that should be necessary. Why shouldn't an emacs,
> found by whatever path, not be able to find its default pdmp file
> in PATH_EXEC? I believe that the search done by emacs is just
> missing a check that would solve this. The problem is that
> load_pdump() in src/emacs.c only searches PATH_EXEC for
> emacs.pdmp, and then for the pdmp file with the name given by:
> 
>       basename(argv[0])
> 
> If it were to also search for
> 
>       basename(realpath(argv[0]))
> 
> then it would find pdmp files that match either the given, or
> "absolute" names, rather than just the given name, and symlinks
> that point at emacs executables would always find the default
> pdmp file that goes with them, whether we deliver them, or the
> user makes their own.

But realpath(argv[0]) can produce to a file in another directory,
because realpath expands all the symlinks, not just that of the
basename.  Does it make sense to look up the .pdmp file in the
directory of the original argv[0] when it is a symlink?

>       - Move the repeated code into functions, to clean up load_pdump().
> 
>       - Save the basename from the result of calling realpath() during the
>         search of the executable directory.
> 
>       - During the PATH_EXEC stage, use the saved realpath basename to
>         add a check for that name.

This is not enough, if we want to support *.pdmp files that have
arbitrary names.  For example, when Emacs is invoked as "../emacs" (or
any other relative file name which includes slashes), we currently
don't expand symlinks, so with your proposal "emacs" and "../emacs"
will behave differently.

IOW, supporting arbitrarily-named *.pdmp files requires more thorough
revision of the logic in load_pdump than just some simple refactoring.
Especially as Emacs 28 will have the native-compilation feature,
whereby it also needs to find at startup the directory with the *.eln
files that correspond to the preloaded Lisp files; see bug#44128.