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

Previous Next

To reply to this bug, email your comments to 79191 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: make bootstrap fails to clear out stale .eln's.  They then get
 wrongly used in the build.
Date: Thu, 7 Aug 2025 15:04:34 +0000

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.

I think these are build bugs needing fixing.  In the meantime, I'd
appreciate somebody suggesting a workaround, so that I can actually do a
proper bootstrap.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>, Andrea Corallo <acorallo <at> gnu.org>
Cc: 79191 <at> debbugs.gnu.org
Subject: Re: 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:31:23 +0300

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

> I think these are build bugs needing fixing.  In the meantime, I'd
> appreciate somebody suggesting a workaround, so that I can actually do a
> proper bootstrap.

The obvious workaround is to delete the subdirectory of eln-cache by
hand.

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

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: Re: 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.