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

Previous Next

Full log

View this message in rfc822 format

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

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

Emacs will scan and hash the source file and load the correct one if
present.

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

Yeah, you see now how terrible is my memory :) please see my other mail
on this.

Thanks

  Andrea

Previous Next

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