GNU bug report logs - #50666
28.0.50; Fix native compilation on Cygwin

Previous Next

Full log

Message #118 received at 50666 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: ASSI <Stromeko <at> nexgo.de>, 50666 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#50666: 28.0.50; Fix native compilation on Cygwin
Date: Fri, 24 Sep 2021 07:26:11 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: ASSI <Stromeko <at> nexgo.de>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Andrea Corallo <akrl <at> sdf.org>,
>>   Stromeko <at> nexgo.de,  50666 <at> debbugs.gnu.org,  Ken Brown
>>  <kbrown <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.