[bug#67260] [PATCH v6 1/7] gnu: emacs: Wrap EMACSNATIVELOADPATH.

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Sonntag, dem 28.01.2024 um 16:17 +0000 schrieb Suhail:
> I'm assuming you're able to reproduce the issue on your end as well
> with
> other features like prog-mode, backquote etc.
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > I instrumented lread.c to print the relative and absolute file
> > names tried, and it appears that these aren't loaded at all after
> > install while EMACSNATIVELOADPATH is ignored when dumping.
> 
> Interesting.  I did a grep of the Emacs source (branch emacs-29) and
> line 1770 of src/lread.c (in maybe_swap_for_eln) seemed relevant:
> 
> >   /* Look also in preloaded subfolder of the last entry in
> >      `comp-eln-load-path'.  */
> 
> What surprised me was that not only was the "preloaded" directory
> special-cased, but so too was the last entry of "comp-eln-load-path"
> (which I imagine is referring to native-comp-eln-load-path).  Judging
> by your message, I'm guessing you're well aware of this.  I,
> unfortunately, have no additional insights or suggestions.
> 
> However, given that ensuring Emacs is able to find the natively-
> compiled version of files seems non-trivial, it might help for a
> future patch series to be accompanied with tests.  Thoughts?
On upstream, this would add ../native-lisp/preloaded to the search
(since everything is dropped in one directory, this probably works as
expected), but with our patch, we do multiple directories *and* drop
../native-lisp from that early.  We could try expanding
EMACSNATIVELOADPATH earlier, but we can't yet use Fgetenv_internal.

But yeah, we're looking at the same source file right now.

Cheers