GNU bug report logs -
#66864
emacs-build-system builds .eln-files with mismatching path-hashes
Previous Next
Full log
Message #11 received at 66864 <at> debbugs.gnu.org (full text, mbox):
2023-11-01 12:52 liliana.prikler <at> gmail.com:
> Am Dienstag, dem 31.10.2023 um 23:49 +0000 schrieb Mekeor
> Melire:
> > 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"?
To be honest, I can't reproduce the leakage right now. I'll create another bug report if I can.
> > 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 :)
I wanted to make sure that an Emacs-related package is installed, and specifically with the --with-input=emacs-minimal=emacs transformation because otherwise .eln-files won't be built. The MRE is minimal in that sense that it ensures what's needed; only one Emacs-related package is installed; and commands are kept simple.
> > 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).
Yes, this is already the bug. The reason for the eln-cache to be created is that the two path-hashes do not equal.
> > 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.
The problem is that the .el-file-path that is passed to the Emacs function comp-el-to-eln-filename during build [1] does not equal to the
.el-file-path when Emacs is invoked. Personally, I do not
understand how grafting causes this. But I can confirm that when
--no-grafts is passed to "guix install emacs emacs-unfill
--with-input=emacs-minimal=emacs", then no eln-cache is created.
[1]: See these lines of code:
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-build-system.scm?h=92913703448c8e1a488ab066f60741262cdbf923#n133
https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-utils.scm?h=92913703448c8e1a488ab066f60741262cdbf923#n149
This bug report was last modified 1 year and 273 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.