bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Dienstag, dem 31.10.2023 um 23:49 +0000 schrieb Mekeor Melire:
> BUG EXPLANATION
> 
> Emacs's natively-compiled .eln-files have a basename following the
> pattern "{feature-name}-{path-hash}-{content-hash}.eln". [0]
> 
> Guix' emacs-build-system is used to build Emacs-related packages. By 
>  default, it uses the "emacs-minimal" package during build, which 
>  does not support native-compilation. But if you replace the 
>  "emacs-minimal" input with "emacs-no-x", e.g. by using 
>  --with-input=emacs-minimal=emacs-no-x, then emacs-build-system 
>  will make use of emacs-no-x' support of native-compilation [1]: 
>  The build will contain .eln-files.
> 
> Hereby I'd like to report the bug that consists of mismatched path-
> hashes in the .eln-files that builds of Emacs-related packages
> contain when build with emacs-no-x (or any other Emacs that supports
> native compilation).
> 
> BUG REPRODUCTION
> 
> To reproduce this bug follow the following steps. Please note that
> guix-shell seems to leak .eln-files. (This should be reported as 
> another bug.)
What do you mean by "leaks .eln-files"?

> That why the reproduction steps avoid guix-shell.  Instead, we'll
> work with the current user profile.
> 
> Delete Emacs' eln-cache (so that we can later see if new 
> .eln-files have been generated):
> 
>         rm -rf ~/.emacs.d/eln-cache
> 
> Remove all Emacs- and Emacs-related packages from Guix profile:
> 
>         guix package -I | cut -f 4 | grep emacs | xargs guix remove
> 
> Install Emacs and emacs-unfill, as exemplary package, while 
> replacing input "emacs-minimal" with "emacs", so that .eln-files 
> are generated during the build:
> 
>         guix install emacs emacs-unfill 
>         --with-input=emacs-minimal=emacs
Just deleting the eln-cache should be enough for a MWE.  When doing an
MWE, make sure that its actually minimal :)

> Launch the freshly installed Emacs and load the "unfill" package. 
> If the .eln-files that the emacs-unfill package provides match 
> Emacs' expectations (path- and content-hash), it'll use it; 
> otherwise, Emacs will compile a new .eln-file and save it into 
> ~/.emacs.d/eln-cache/*/unfill-{path-hash}-{content-hash}.eln.
> 
>         emacs -q --eval "(require 'unfill)"
> 
> Close Emacs after some seconds. Now determine the path-hash from 
> Guix' build:
> 
>         basename 
>         ~/.guix-profile/lib/emacs/native-site-lisp/*/unfill-*.eln \
>           | cut -d - -f 2
> 
> Determine the path-hash from Emacs' native-compilation, which 
> apparently has happened:
> 
>         basename ~/.emacs.d/eln-cache/*/unfill*.eln \
>           | cut -d - -f 2
This is already the bug.  There should not be a file written to the
eln-cache (save for the trampolines that we still write there, which is
also a known bug among those who care).

> The path-hashes from the last two steps are not equal.
> 
> BUG SOLUTION HINTS
> 
> In the #guix:libera.chat IRC channel, jpoiret pointed out: "the .eln
> file hash problem is due to grafts, grafts change the 
> final output name, but they can't also update the file hashes... 
> we'd need to modify emacs' behavior for this to work".
As jpoiret points out, this has to do with the file naming choices of
Emacs, not with emacs-build-system per se.  We would need to get rid of
a lot of hashes if we wanted interoperable native-compiled Emacs
libraries.  I wonder what upstream has to say about this.

Cheers