bug#48578: 28.0.50; Native-compiled files of some preloaded files not loaded at dump time

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: 48578@debbugs.gnu.org
> Date: Mon, 24 May 2021 08:48:39 +0000
> 
> > Suggestions for where to look for the reasons of the problem?
> 
> I'd start verifying what given the el source file
> `comp-el-to-eln-rel-filename' suggests as eln filename and if this is
> present as native compiled file (I guess so if you recompiled manually).
> 
> The next step would be verifying why when loading in lread.c
> 'maybe_swap_for_eln' does not decide to load the eln file in place of
> the elc one.

Thanks.  The problem is in comp-el-to-eln-rel-filename, in this
fragment at its beginning:

  /* Use `file-truename' or fall back to `expand-file-name' when the
     first is not available (bug#44701).

     `file-truename' is not available only for a short phases of the
     bootstrap before file.el is loaded, given we do not symlink
     inside the build directory this should work.  */
  filename = NILP (Ffboundp (intern_c_string ("file-truename")))
    ? Fexpand_file_name (filename, Qnil)
    : CALL1I (file-truename, filename);

During loadup, file-truename is not available until files.elc/eln is
loaded.  But the assumption above that it isn't a problem because "we
do not symlink inside the build directory" in false in my case,
because my home directory, where I build Emacs, is itself a symlink:

  (expand-file-name "~") => "/home/e/eliz"
  (file-truename "~") => "/srv/data/home/e/eliz"

So every one of the *.eln files loaded before and including files.elc
will fail in the above logic and will produce a different path_hash,
thus failing the attempt to find the correct .eln file.

We could use 'realpath' (and a suitable emulation on WINDOWSNT)
instead of file-truename.