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
Message #8 received at 79191 <at> debbugs.gnu.org (full text, mbox):
> 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.
This bug report was last modified 12 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.