GNU bug report logs -
#78285
31.0.50; load-prefer-newer causes recursive load on Windows
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 78285 in the body.
You can then email your comments to 78285 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78285
; Package
emacs
.
(Tue, 06 May 2025 22:05:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gary Oberbrunner <garyo <at> oberbrunner.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 06 May 2025 22:05:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Recent Emacs on Windows gets errors trying to recursively load during
startup. I'm using prebuilt msix installer from kiennq
(https://github.com/kiennq/emacs-build), and both the ucrt and regular
versions show this bug. I have not built Emacs myself on Windows in a
while, but the kiennq builds are usually solid.
Emacs -Q is OK, but this minimal setup shows the problem:
In $HOME/.config/emacs/init.el:
(setq load-prefer-newer t)
Then start Emacs as usual. You will see startup taking a lot more time than
usual, and then in *Messages* you'll see many errors like this one:
Error muted by safe_call: (apply native--compile-async (
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/cl-extra.el.gz"
nil late))
signaled (error "Recursive load"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/ring.el.gz"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/comint.elc"
"c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/progmodes/compile.elc")
As you can see, these errors are suppressed in this test case, but in a
real Emacs session,
later on the same errors prevent loading various files, so my init.el
never finishes loading. As an example of that, I get this error with my
actual emacs config:
error: Recursive load,
c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/radix-tree.el.gz,
c:/Program
Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/loaddefs-gen.elc,
c:/Users/garyo/.config/emacs/lisp/elpaca-bootstrap.el,
c:/Users/garyo/.config/emacs/init.el
In GNU Emacs 31.0.50 (build 1, x86_64-w64-mingw32) of 2025-05-01 built
on fv-az1115-294
Repository revision: 3b18648e3daf021a37ca8aa71ee69fb3e8b79de9
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.22635
System Description: Microsoft Windows 10 Pro (v10.0.2009.22635.5025)
Configured using:
'configure
--prefix=/d/a/emacs-build/emacs-build/pkg/3b18648-ucrt-x86_64
'CFLAGS=-O2 -fno-semantic-interposition -floop-parallelize-all
-ftree-parallelize-loops=4 -g3 ' --disable-build-details --without-dbus
--enable-link-time-optimization --enable-build-details
--with-compress-install --with-small-ja-dic --with-gif --with-gnutls
--with-harfbuzz --with-jpeg --with-json --with-lcms2 --with-mps
--with-native-compilation --with-png --with-rsvg --with-tree-sitter
--with-xml2 --with-xpm --with-zlib --without-cairo --without-tiff'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES MPS NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
Important settings:
value of $LC_ALL:
value of $LC_COLLATE: C
value of $LANG: en_US.utf-8
locale-coding-system: cp1252
Major mode: Elisp/l
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils thingatpt time-date help-fns
byte-opt gv radix-tree pcase misearch multi-isearch vc-git diff-mode
track-changes easy-mmode files-x vc-dispatcher compile
text-property-search comint subr-x ansi-osc ansi-color ring cl-seq
comp-run bytecomp byte-compile comp-common rx cl-extra help-mode
warnings icons cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc
paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode
mwheel touch-screen dos-w32 ls-lisp term/w32-nt disp-table term/w32-win
w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process
tty-child-frames native-compile mps emacs)
Memory information:
((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0)
(vectors 24 0) (vector-slots 8 0 0) (floats 24 0 0)
(intervals 64 0 0) (buffers 1000 0))
--
Gary
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78285
; Package
emacs
.
(Wed, 07 May 2025 11:28:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 78285 <at> debbugs.gnu.org (full text, mbox):
> From: Gary Oberbrunner <garyo <at> oberbrunner.com>
> Date: Tue, 6 May 2025 18:04:22 -0400
>
> Recent Emacs on Windows gets errors trying to recursively load during
> startup. I'm using prebuilt msix installer from kiennq
> (https://github.com/kiennq/emacs-build), and both the ucrt and regular versions show this bug. I have not
> built Emacs myself on Windows in a while, but the kiennq builds are usually solid.
>
> Emacs -Q is OK, but this minimal setup shows the problem:
>
> In $HOME/.config/emacs/init.el:
>
> (setq load-prefer-newer t)
>
> Then start Emacs as usual. You will see startup taking a lot more time than
> usual, and then in *Messages* you'll see many errors like this one:
>
> Error muted by safe_call: (apply native--compile-async (
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/cl-extra.el.gz"
>
> nil late))
> signaled (error "Recursive load"
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz"
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/ring.el.gz"
>
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/comint.elc"
> "c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/progmodes/compile.elc")
>
>
> As you can see, these errors are suppressed in this test case, but in a real Emacs session,
> later on the same errors prevent loading various files, so my init.el
> never finishes loading. As an example of that, I get this error with my
> actual emacs config:
>
> error: Recursive load,
> c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
> c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
> c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
> c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
> c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/jka-compr.el.gz,
> c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/radix-tree.el.gz,
>
> c:/Program
> Files/WindowsApps/emacs-k_31.340.0.0_x64__tewns1xw2exn6/share/emacs/31.0.50/lisp/emacs-lisp/loaddefs-gen.elc,
>
> c:/Users/garyo/.config/emacs/lisp/elpaca-bootstrap.el,
> c:/Users/garyo/.config/emacs/init.el
As can be seen from the above, your configuration loads
elpaca-bootstrap.el, whose contents you haven''t shown. Then Emacs
loads loaddefs-gen.elc, which wants to load radix-tree.elc, but
instead loads radix-tree.el.gz for some reason.
So there are several issues here that only you can investigate:
. why does elpaca-bootstrap want to load loaddefs-gen at startup?
. does Emacs load radix-tree.el.gz instead of radix-tree.elc? could
it be that the time stamps in your installation tree are somehow
messed up? on my systems, all the *.elc files in the installation
tree are newer than the corresponding *.el.gz files, so setting
load-prefer-newer non-nil doesn't cause any problems
Please look into these issues and sere what you find.
P.S. The prebuilt msix installer from kiennq is not something we
support here, so perhaps you should ask the persons who make that
distribution to help you.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78285
; Package
emacs
.
(Wed, 07 May 2025 12:21:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 78285 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> As can be seen from the above, your configuration loads
> elpaca-bootstrap.el, whose contents you haven''t shown. Then Emacs
> loads loaddefs-gen.elc, which wants to load radix-tree.elc, but
> instead loads radix-tree.el.gz for some reason.
Actually I gave a minimal one-line repro case without elpaca. Just create
init.el with this:
> (setq load-prefer-newer t)
and then check the *Messages* buffer.
I did report this issue to the packager (kiennq) who suggested I also raise
an issue here.
--
Gary
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78285
; Package
emacs
.
(Wed, 07 May 2025 12:51:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 78285 <at> debbugs.gnu.org (full text, mbox):
> From: Gary Oberbrunner <garyo <at> oberbrunner.com>
> Date: Wed, 7 May 2025 08:20:36 -0400
> Cc: 78285 <at> debbugs.gnu.org
>
> > As can be seen from the above, your configuration loads
> > elpaca-bootstrap.el, whose contents you haven''t shown. Then Emacs
> > loads loaddefs-gen.elc, which wants to load radix-tree.elc, but
> > instead loads radix-tree.el.gz for some reason.
>
> Actually I gave a minimal one-line repro case without elpaca. Just create init.el with this:
>
> > (setq load-prefer-newer t)
>
> and then check the *Messages* buffer.
Granted, I already tried that, and it didn't happen for me.
If the traces you show in your original report are not relevant for
the reproduction recipe, please show the same traces for the latter.
Did you make sure that all the *.elc files in the installation tree
are newer that the corresponding *.el.gz files?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78285
; Package
emacs
.
(Wed, 07 May 2025 13:17:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 78285 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, May 7, 2025 at 8:50 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Gary Oberbrunner <garyo <at> oberbrunner.com>
> > Date: Wed, 7 May 2025 08:20:36 -0400
> > Cc: 78285 <at> debbugs.gnu.org
> >
> > > As can be seen from the above, your configuration loads
> > > elpaca-bootstrap.el, whose contents you haven''t shown. Then Emacs
> > > loads loaddefs-gen.elc, which wants to load radix-tree.elc, but
> > > instead loads radix-tree.el.gz for some reason.
> >
> > Actually I gave a minimal one-line repro case without elpaca. Just
> create init.el with this:
> >
> > > (setq load-prefer-newer t)
> >
> > and then check the *Messages* buffer.
>
> Granted, I already tried that, and it didn't happen for me.
>
> If the traces you show in your original report are not relevant for
> the reproduction recipe, please show the same traces for the latter.
>
> Did you make sure that all the *.elc files in the installation tree
> are newer that the corresponding *.el.gz files?
>
Ah, OK, good info. If it doesn't happen for you (I presume you're compiling
the latest master branch on Windows) then it may be specific to the
package.
Looking into it further, the .el.gz is newer than the .elc:
-rw-r--r-- 1 garyo garyo 7477 May 6 16:45 jka-compr.el.gz
-rw-r--r-- 1 garyo garyo 12168 Sep 3 2024 jka-compr.elc
so I think I understand the problem now. load-prefer-newer tells emacs to
use jka-compr.el.gz rather than jka-compr.elc, and to use that, it will
need to decompress it, which means it'll need to load the decompressor,
which comes from jka-compr. And boom.
Given the file dates above it's pretty clear the build I'm using is the
cause of the problem. So you can close this bug report and I'll follow up
there.
--
Gary
[Message part 2 (text/html, inline)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Thu, 08 May 2025 09:43:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gary Oberbrunner <garyo <at> oberbrunner.com>
:
bug acknowledged by developer.
(Thu, 08 May 2025 09:43:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 78285-done <at> debbugs.gnu.org (full text, mbox):
> From: Gary Oberbrunner <garyo <at> oberbrunner.com>
> Date: Wed, 7 May 2025 09:15:51 -0400
> Cc: 78285 <at> debbugs.gnu.org
>
> On Wed, May 7, 2025 at 8:50 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Gary Oberbrunner <garyo <at> oberbrunner.com>
> > Date: Wed, 7 May 2025 08:20:36 -0400
> > Cc: 78285 <at> debbugs.gnu.org
> >
> > > As can be seen from the above, your configuration loads
> > > elpaca-bootstrap.el, whose contents you haven''t shown. Then Emacs
> > > loads loaddefs-gen.elc, which wants to load radix-tree.elc, but
> > > instead loads radix-tree.el.gz for some reason.
> >
> > Actually I gave a minimal one-line repro case without elpaca. Just create init.el with this:
> >
> > > (setq load-prefer-newer t)
> >
> > and then check the *Messages* buffer.
>
> Granted, I already tried that, and it didn't happen for me.
>
> If the traces you show in your original report are not relevant for
> the reproduction recipe, please show the same traces for the latter.
>
> Did you make sure that all the *.elc files in the installation tree
> are newer that the corresponding *.el.gz files?
>
> Ah, OK, good info. If it doesn't happen for you (I presume you're compiling the latest master branch on
> Windows) then it may be specific to the package.
>
> Looking into it further, the .el.gz is newer than the .elc:
>
> -rw-r--r-- 1 garyo garyo 7477 May 6 16:45 jka-compr.el.gz
> -rw-r--r-- 1 garyo garyo 12168 Sep 3 2024 jka-compr.elc
>
> so I think I understand the problem now. load-prefer-newer tells emacs to use jka-compr.el.gz rather than
> jka-compr.elc, and to use that, it will need to decompress it, which means it'll need to load the
> decompressor, which comes from jka-compr. And boom.
> Given the file dates above it's pretty clear the build I'm using is the cause of the problem. So you can close
> this bug report and I'll follow up there.
Thanks, closing.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 05 Jun 2025 11:24:15 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.