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

[Andy Moreton]

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.

      AndyM