On Wed, May 7, 2025 at 8:50 AM Eli Zaretskii <eliz@gnu.org> wrote:

> From: Gary Oberbrunner <garyo@oberbrunner.com>
> Date: Wed, 7 May 2025 08:20:36 -0400
> Cc: 78285@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