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

[Jim Myhrberg]

HI Andrea,

I'm afraid it's still not picking up the *.eln files from within the
app bundle. I tried inverting those two variables myself last night
without any luck.

Anything I can check on my end to yield some more light on what's going on?

On Tue, Sep 22, 2020 at 8:59 AM Andrea Corallo <akrl@sdf.org> wrote:
>
> Jim Myhrberg <contact@jimeh.me> writes:
>
> > Hi Andrea,
> >
> > I've just tested that branch, and I'm afraid it doesn't work. It
> > starts native compiling cconv.el and others like before. Looking at
> > the changes, I believe it's looking for "Emacs.app" within
> > PATH_DUMPLOADSEARCH, which didn't actually contain that in my build
> > directory, it was PATH_LOADSEARCH that did. So currently that branch
> > doesn't find the bundled *.eln files even when the app is named
> > "Emacs.app".
> >
> > And annoyingly we also need to support it if the user renames the app
> > to something else, like "Emacs 28.app", or "Emacs Native.app", or even
> > something crazy like "fooBar! LaLa.app".
> >
> > My knowledge of C is mostly non-existent, but in an effort to reduce
> > the feedback loop and not take up too much of your time, I'll try some
> > guess-based tweaks and see if I have any success :)
> >
> > Thanks again :)
>
> Hi Jim,
>
> apologies to a quick look I've inverted PATH_LOADSEARCH and
> PATH_DUMPLOADSEARCH in the code :/
>
> I've also addressed the *.app suggestion (yesterday I've missed your
> mail).
>
> Lets see if I got it right now.
>
> Thanks
>
>   Andrea