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

Previous Next

Full log

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: andrewjmoreton <at> gmail.com, dmalcolm <at> redhat.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 19:40:26 +0000

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

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> 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 18:52:55 +0000
>>> 
>>> >> Is the application responsible for cleaning up temporary files in '/tmp?
>>> >> If yes then yes... I guess we should :)
>>> >
>>> > I think it's good practice, yes.
>>> 
>>> 8e524f4591 fix this.
>>
>> Thanks, confirmed.
>>
>> Btw, I have now 3 different *.eln files for comp.el in the same
>> subdirectory of native-lisp:
>>
>>   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').
>
> 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.

Okay apparently we did it already in the past (be22cda7be) but I
reverted the commit with d0280ce1b1.  The commit message for this says:

"Older binaries might still need those .eln if they where preloaded."

I guess the issue is clear now and we should be able to better tackle it
once we depose the preloaded .eln in the preloaded subfolder (I think
I'll be on that this weekend).

Thanks

  Andrea

Previous Next

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