bug#52376: 28.0.90; libdir is missing from native-comp-eln-load-path with GTK3 build

[Eli Zaretskii <eliz@gnu.org>]

> From: Bhavin Gandhi <bhavin7392@gmail.com>
> Date: Fri, 10 Dec 2021 21:17:38 +0530
> Cc: 52376@debbugs.gnu.org, akrl@sdf.org
> 
> On Fri, 10 Dec 2021 at 20:38, Eli Zaretskii <eliz@gnu.org> wrote:
> > > Which probably means the .pdmp file is somehow devoid of
> > > natively-compiled code, i.e. it was produced by dumping the *.elc
> > > files, not the *.eln files?
> >
> > Does the command below show anything at all?
> >
> >   $ strings /usr/bin/emacs-28.0.90.pdmp | fgrep .eln
> 
> Only one string.
> 
> $ strings /usr/bin/emacs-28.0.90.pdmp | fgrep .eln
> \.eln\'

So we now know this emacs.pdmp file was produced by dumping the *.elc
files, not *.eln files.  I asked you earlier whether you saw Emacs
saying stuff like

   Loading foo (native-compiled lisp)...

when building the GTK build, and you said yes.  But somehow, the
emacs.pdmp file that you installed in /usr/bin isn't the one produced
as above.  Please examine your build procedure to understand why that
happened.

> > Actually, thinking about it now: why is the emacs.pdmp file in
> > /usr/bin?  It should be under /usr/libexec/emacs/28.0.90/.
> 
> Yeah, I had to do it to support installation of different binaries like
> emacs, emacs-lucid, emacs-nox on the same system. The hardcoded case
> from emacs.c:917, which uses path_exec, looks only for the emacs.pdmp file
> and not the executable name i.e. emacs-28.0.90.pdmp in my case.
> 
>   /* Look for "emacs.pdmp" in PATH_EXEC.  We hardcode "emacs" in
>      "emacs.pdmp" so that the Emacs binary still works if the user
>      copies and renames it.  */

Please reconsider.  When Emacs finds the .pdmp file near its
executable, it makes certain assumptions about the location of the
*.eln files that don't fit the installed Emacs.  So placing the .pdmp
files there is not a good idea.