Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Hi Eli,

I see, it would then look something like the attached I guess.

It does bootstrap on GNU/Linux but I'm no expert on how to fill the
WINDOWSNT ifdef branch.

Thanks

  Andrea