GNU bug report logs - #43532
[feature/native-comp] *.eln file name hashing, algorithm doesn't seem to play nice with NATIVE_FULL_AOT with self-contained builds

Previous Next

Package: emacs;

Reported by: Jim Myhrberg <contact <at> jimeh.me>

Date: Sun, 20 Sep 2020 13:04:01 UTC

Severity: normal

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Andrea Corallo <akrl <at> sdf.org>
To: Jim Myhrberg <contact <at> jimeh.me>
Cc: 43532 <at> debbugs.gnu.org
Subject: bug#43532: [feature/native-comp] *.eln file name hashing algorithm doesn't seem to play nice with NATIVE_FULL_AOT and self-contained Emacs.app builds for macOS
Date: Mon, 21 Sep 2020 07:53:41 +0000
Jim Myhrberg <contact <at> jimeh.me> writes:

> Hi,
>
> TL;DR:
>
> If I've understood correctly, the filename of the cached *.eln files
> includes a hash based on the absolute file path and content of the
> source *.el/*.el.gz file. On macOS when producing a self-contained
> Emacs.app bundle this means that the cached *.eln files bundled into
> the app cannot be used, as their absolute path won't match what they
> were during build time. And app bundles on macOS can be placed and
> launched from anywhere on disk.

Hi Jim,

I think we should be able to improve the filename hashing mechanism on
MacOS to deal with that.  Perhaps something like removing
*/Emacs.app/Contents/MacOS/ from the input of it.

Could you post the value of PATH_DUMPLOADSEARCH and PATH_LOADSEARCH
macros?  You should find them defined in epaths.h in your build
directory.

Thanks

  Andrea




This bug report was last modified 4 years and 278 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.