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
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
Message #95 received at 43532 <at> debbugs.gnu.org (full text, mbox):
Haha, apologies for the nightmare. There are few things worse than
writing code you can't actually test and run yourself
<insert-some-form-of-nightmare-emoji>
With 915214a the application is now structured correctly, but I'm
afraid it doesn't look to be truncating the paths correctly during the
initial build process. As the *.eln files bundled into the app bundle
during the build process with NATIVE_FULL_AOT=1 are ignored. But *.eln
files dynamically compiled into the user eln-cache directory are
re-used regardless of where you place the application on disk.
And relevant stuff from epaths.h just to be safe:
#define PATH_LOADSEARCH
"/Users/jimeh/Projects/build-emacs-for-macos/sources/emacs-mirror-emacs-915214a/nextstep/Emacs.app/Contents/Resources/lisp"
#define PATH_REL_LOADSEARCH "Contents/Resources"
#define PATH_DUMPLOADSEARCH
"/Users/jimeh/Projects/build-emacs-for-macos/sources/emacs-mirror-emacs-915214a/lisp"
And thanks again for all your work :)
On Sun, Oct 4, 2020 at 9:54 PM Andrea Corallo <akrl <at> sdf.org> wrote:
>
> Jim Myhrberg <contact <at> jimeh.me> writes:
>
> > Thanks Andrea,
> >
> > I just created a build from commit 44ef243, and it did not work out
> > quite as expected :)
>
> This 43532 is becoming my nightmare :)
>
> 915214ac9a should fix.
>
> Thanks for testing.
>
> 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.