Subject: bug#72045: Emacs graft lookup still fails

From: Liliana Marie Prikler <[email-masked]>
Date: Sun, 14 Jul 2024 10:50:41 +0200

Am Samstag, dem 13.07.2024 um 19:22 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler <[email-masked]> 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.
Nitpick: Emacs 29.4 gets grafted in at profile-building time.

> 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.
That kinda defeats the point of grafting, though.  At this point,
rebuilding with newer Emacs makes more sense.

> 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.
Given that the ABI hash is used to guard against loading outdated
libraries like this, I'm not sure whether this makes too much sense.  I
think what we would need is something like 

3. Accurately capture the compatibility between Emacs-used-to-compile
   and Emacs-used-to-run.  I.e. find a way to enable Emacs cross
   compilation.

Perhaps upstream already has some ideas on this, perhaps not.

> 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).
I think 1 could be accomplished with a build system hack, but see
above.

Cheers