Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree

From: Andy Moreton <[email-masked]>
Date: Fri, 05 Feb 2021 23:55:10 +0000

On Thu 04 Feb 2021, Andy Moreton wrote:

> On Thu 04 Feb 2021, Andy Moreton wrote:
>
>> On Wed 03 Feb 2021, akrl--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>>>
>>> Hi Andy,
>>>
>>> could you share the values of PATH_DUMPLOADSEARCH and
>>> PATH_REL_LOADSEARCH from your epaths.h ?
>>>
>>> Thanks
>>>
>>>   Andrea
>>
>> Native branch checkout is in: "c:/emacs/git/emacs/native/"
>>
>> "c:/emacs/git/emacs/native/build/mingw64-x86_64-O2/src/epaths.h" contains:
>>
>> #define PATH_DUMPLOADSEARCH "C:/emacs/git/emacs/native/lisp"
>> #define PATH_REL_LOADSEARCH "28.0.50/lisp"
>
> I've bootstrapped again after the recent hash shortening to ensure my build
> is up to date, from commit 1f626e9662d8120acd5a937f847123cc2b8c6e31. The
> paths above are unchanged.
>
> Running this from the build dir, I see messages like:
>
> error in process sentinel: Native elisp load failed: "file does not exists",
>  "c:/home/ajm/.emacs.d/eln-cache/28.0.50-e2ae3598/hl-line-e67628ec-664ef650.eln"
>
> This suggests that the AOT .eln files are not being found. It should find:
>
> c:/emacs/git/emacs/native/build/mingw64-x86_64-O2/native-lisp/28.0.50-e2ae3598/hl-line-8fa29c14-664ef650.eln
>
> The middle hash (e67628ec vs. 8fa29c14) is not the same - any idea why ?

After looking at what `comp-el-to-eln-filename' does, I observe that:

(substring (md5 "c:/emacs/git/emacs/native/lisp/hl-line.el") 0 8)
"e67628ec"

(substring (md5 "//hl-line.el") 0 8)
"8fa29c14"

That matches the two middle hashes seen above.

It looks like `comp-el-to-eln-filename` fails to match the filename
prefix against PATH_DUMPLOADSEARCH. It is using case-sensitive matching,
but on Windows filesystems are case-insensitive.

    AndyM