bug#50666: 28.0.50; Fix native compilation on Cygwin

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: ASSI <Stromeko@nexgo.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Andrea Corallo <akrl@sdf.org>,
>>   Stromeko@nexgo.de,  50666@debbugs.gnu.org,  Ken Brown
>>  <kbrown@cornell.edu>
>> Date: Fri, 24 Sep 2021 08:04:09 +0200
>> 
>> You can't rebase an object that is already loaded on Windows (or load an
>> object that is in the process of getting rebased), so I would not worry
>> about this situation too much at the moment.
>
> This means that the following situation will predictably fail:
>
>   . Emacs session A (or just some shell command) rebases a .eln file
>   . Emacs session B decides it needs to load that .eln
>
> What kind of failure will session B see in this case?  Is it possible
> to figure out somehow that this is the reason, so that we could
> instead try loading the .elc or .el?
>
> Or maybe we should add an automatic fallback on .elc/.el in case
> loading a .eln fails?  Andrea, WDYT? will that work?

Yes I think we could have an automatic fallback, we might have
'native-elisp-load' (invoked by 'load') re invoke load itself in case of
failure, not very clean tho.

But aside the fact that is implementable I think it should be limited to
just this specific load failure, otherwise it could easily mask other
issues.  And this raise another question: can we identify this specific
kind of load failure?

  Andrea