[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#72045: Emacs graft lookup still fails
From: |
Suhail Singh |
Subject: |
bug#72045: Emacs graft lookup still fails |
Date: |
Sat, 13 Jul 2024 19:22:46 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> with the grafting of Emacs 29.3 to 29.4, we see that Emacs itself is
> still correctly loaded, but Emacs libraries (e.g. dash) aren't.
>
> (comp-el-to-eln-filename (expand-file-name "…/dash.el"))
> => $HOME/.config/emacs/eln-cache/29.4-46e5bcbe/dash-2.19.1/dash.eln
>
> find $(guix build emacs-dash --with-input=…) -name 'dash.eln'
> => $PREFIX/lib/emacs/native-site-lisp/29.3-62809b9a/dash.eln
>
> It seems that we might have to rebuild emacs native-compiled packages
> even if emacs itself is grafted.
I had missed this message, previously.
IIUC, the issue is that replacement packages are grafted post-build.
This means that when emacs-dash is built, its AOT native-compilation
happens with Emacs 29.3. However, at run-time Emacs 29.4 gets grafted
in.
There are at least two possible ways (ignoring feasibility) to resolve
this:
1. When emacs-dash etc. is being built we use Emacs 29.4 for native
compilation.
2. When emacs-dash etc. is being built we use Emacs 29.3 for native
compilation, but ensure that said files are transferred to a location
where Emacs 29.4 is able to find them.
Which do we desire? My belief is that 1 is what we need, and that doing
2 may be inadequate for ensuring that appropriate security fixes are
deployed (consider the case where the bug is in a macro in Emacs core).
If my analysis above is correct, then the question (which I don't know
the answer to) is can 1 be accomplished with grafts?
--
Suhail
bug#72045: Emacs graft lookup still fails,
Suhail Singh <=
bug#72045: [PATCH v2 1/2] gnu: Add system test for Emacs., Liliana Marie Prikler, 2024/07/19