Subject: bug#50666: 28.0.50; Fix native compilation on Cygwin

From: Andrea Corallo <[email-masked]>
Date: Fri, 24 Sep 2021 07:26:11 +0000

Eli Zaretskii <[email-masked]> writes:

>> From: ASSI <[email-masked]>
>> Cc: Eli Zaretskii <[email-masked]>,  Andrea Corallo <[email-masked]>,
>>   [email-masked],  [email-masked],  Ken Brown
>>  <[email-masked]>
>> 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