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

Previous Next

Full log

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

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

> 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?

Previous Next

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