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

[Andy Moreton <andrewjmoreton@gmail.com>]

On Fri 19 Feb 2021, Eli Zaretskii wrote:

>> Cc: 46256@debbugs.gnu.org
>> Date: Thu, 18 Feb 2021 21:00:29 +0000
>> From:  Andrea Corallo via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> >> 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).
>
> If the problem is with hashing file names, you will have to
> canonicalize them first, including resolving the letter-case issue,
> the forward/back-slashes issue, and also the issue with those pesky
> numerical tails Windows sometimes produces.  We have a function
> Fw32_long_file_name for that purpose, I think you should use it (if
> you need it for C strings, we could add a wrapper around
> w32_get_long_filename to do that instead).  This assumes that you are
> talking about existing files; if that assumption is not true, we will
> need a slightly different strategy.

The problem is with the file names used to generate the hashes, where
comparison of file names.

As an experiment, I changed epaths.h from:
#define PATH_DUMPLOADSEARCH "C:/emacs/git/emacs/native/lisp"

to:
#define PATH_DUMPLOADSEARCH "c:/emacs/git/emacs/native/lisp"

and then ran make (to build without regenerating the header).
The resulting emacs did not complain about mismatched filenames.

Thus the fix outlined by Eli above looks like it will solve the problem.

    AndyM