GNU bug report logs - #46495
28.0.50; [native-comp] Build fails for 32bit --with-wide-int

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: andrewjmoreton <at> gmail.com, 46495 <at> debbugs.gnu.org
Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit
 --with-wide-int
Date: Wed, 31 Mar 2021 22:35:30 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: andrewjmoreton <at> gmail.com, dmalcolm <at> redhat.com, 46495 <at> debbugs.gnu.org
> Date: Wed, 31 Mar 2021 19:22:54 +0000
> 
> >   comp-7672a6ed-ad0cbb8b.eln
> >   comp-7672a6ed-58fb0518.eln
> >   comp-7672a6ed-9f0b1563.eln
> >
> > Is this expected?  What does the second hash depend on?
> 
> The second hash is the one based on the source file content.
> 
> I see why, every time we compile a new eln we call
> `comp-clean-up-stale-eln' to remove the old .eln.  But we exclude from
> the clean-up the eln system directory (the last in
> `comp-eln-laod-path').

So with these 3 files in that directory, which one will be loaded by
Emacs, and how will Emacs know which to load?

> I don't remember if the reason is that when Emacs is installed this is
> typically read only or there's some other reason.  Probably we should
> remove this limitation and handle correctly the case where we are not
> able of removing the file if necessary.

Probably.  But didn't you try that recently and found that something
broke as result?

Previous Next

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