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

[Andrea Corallo]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Wed 17 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss 
> army knife of text editors" wrote:
>
>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>
>>> 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.
>>
>> Hi Andy,
>>
>> The Windows filesystem is case-insensitive but the case is preserved
>> correct?  If so it should work no?
>
> Yes, Windows filesystems are case-preserving and do case-insensitive
> lookup. The fact the code complains about the file not existing, and the
> hashes matching as described earlier shows it is clearnly not working. I
> have conjectured why, but the reason may well be something else.
>
>> Last queston: do reverse slashes '\' appear somewhere in those
>> filenames?  This was issue I tried to fix with the blind patch I've
>> sent.
>
> As Eli pointed out, that is not the problem: forward slashes are ok.

I understand they are handled, but here as we do a substitution we must
substitute what's coming in.

As you have the possibility to debug this piece of code on Windows
please have a look at this (or try my blind patch if you haven't).

Thanks

  Andrea