GNU bug report logs - #79191
make bootstrap fails to clear out stale .eln's. They then get wrongly used in the build.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: acm <at> muc.de, 79191 <at> debbugs.gnu.org
Subject: bug#79191: make bootstrap fails to clear out stale .eln's. They then get wrongly used in the build.
Date: Thu, 07 Aug 2025 18:40:32 +0300

> Cc: 79191 <at> debbugs.gnu.org
> Date: Thu, 07 Aug 2025 18:31:23 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Thu, 7 Aug 2025 15:04:34 +0000
> > From: Alan Mackenzie <acm <at> muc.de>
> > 
> > Hello, Emacs.
> > 
> > I've recently changed a C structure layout (in particular, struct
> > thread_state in thread.h), and tried to rebuild Emacs with make
> > bootstrap.
> > 
> > With native compilation disabled, this works, and the resulting Emacs
> > runs satisfactorally.
> > 
> > With native compilation enabled, the build throws segmentation faults
> > just as it starts to compile the compiler natively.  The brief backtrace
> > on my screen includes lines like:
> > 
> >    /home/acm/.emacs.d/eln-cache/31.0.50-6953b951/bytecomp-12882072-8edd60a1.eln(F627974652d636f6d70696c652d2d66756e6374696f6e2d7369676e6174757265_byte_compile__function_signature_0+0x240) [0x7f812bedfb60]
> > 
> > ..  This indicates that the build system is wrongly using stale .eln's
> > rather than the newly build .elc's, despite being requested to make
> > bootstrap.
> > 
> > Why was directory ~acm/.emacs.d/eln-cache/31.0.50-6953b951 not deleted on
> > the make bootstrap?  It no longer has any purpose.  The whole point of
> > make bootstrap is to start a build with a clean slate.
> > 
> > Why were these stale .eln's used in the build?  This is even worse.  This
> > could be one reason why, some while ago, the Emacs build failed to
> > produce reproducible binaries.
> 
> Andrea, could you please look into this?  It sounds like we should
> tweak native-comp-eln-load-path during the build or something?

Come to think of it, I don't understand why Emacs loaded those *.eln
files from the cache.  Changes on the C level that are incompatible
should cause a new hash to be generated, and the name of the eln-cache
sub-directory, 31.0.50-6953b951, should no longer match what Emacs
looks for.

Perhaps the reason is that such changes need to bump ABI_VERSION?

Previous Next

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