bug#43137: 28.0.50; [feature/native-comp] .eln path fixup confused using relative paths

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Andreas Fuchs <asf@boinkor.net> writes:

> On macos (if you use --with-ns), there are two ways the emacs binary
> gets installed:
>
> * as <prefix>/bin/emacs, as normal
> * as <prefix>/Application/Emacs.app/Contents/MacOS/Emacs, in a macOS
> app
>   bundle.
>
> Both of these cause problems, unfortunately:
>
> The "normal" emacs binary you can't invoke from $PATH:
>
> $ emacs -q --batch --eval '(message "hi")'
> emacs: dlopen(../eln-cache/x86_64-apple-darwin19.6.0-9cab85d51a8656a0
> /
> lisp-mode-0189ba85598c041b7504f0a916c04219-5bf5ce8701bca2b361b97967a6f95776.eln,
> 1): image not found
>
> But it does work when run with an absolute path:
>
> $ /nix/store/a55i9aws0j96z0zfzxfffmfb6k2lw53v-emacs-gcc-20200814.0/
> bin/emacs -q --batch --eval '(message "hi")'
> hi
>
>
> The app bundle Emacs, on the other hand, doesn't like the relative
> path
> at all either:
>
> $ /nix/store/a55i9aws0j96z0zfzxfffmfb6k2lw53v-emacs-gcc-20200814.0/
> Applications/Emacs.app/Contents/MacOS/Emacs
> emacs: dlopen(/nix/store/
> a55i9aws0j96z0zfzxfffmfb6k2lw53v-emacs-gcc-20200814.0/Applications/
> Emacs.app/Contents/MacOS/../eln-cache/
> x86_64-apple-darwin19.6.0-9cab85d51a8656a0/
> lisp-mode-0189ba85598c041b7504f0a916c04219-5bf5ce8701bca2b361b97967a6f95776.eln,
> 1): image not found
>  
> I have traced both of these down to the relocation logic in
> pdumper.c:
> https://github.com/emacs-mirror/emacs/blob/feature/native-comp/src/
> pdumper.c#L5255-L5277
>
> This code (and the corresponding bit in
> https://github.com/emacs-mirror/emacs/blob/feature/native-comp/lisp/
> loadup.el#L471-L477
> both seem to take the absolute installation directory and turn them
> into
> relative directories that then fail to work. That the plain "emacs"
> binary fails to run might be due to the fact that
> `invocation-directory`
> is not set in that case, and so it has nothing to prepend to the
> relative name.
>
> In nix, an installation never moves - it's a content-addressed store,
> so
> there's a very fixed pathname that everything lives at forever; is
> it possible to turn off that pathname relativization?
>
> Alternatively, I guess for darwin I'd also be good if we could get
> the
> correct relative names in the application bundle; There is just one
> `../Resources` too few in there. I think to handle this right, we'd
> have
> to add another case to the installation_state enum in pdumper.c, is
> that right?
>
> Cheers,
> Andreas.

Hi Andreas,

I think we might have two issues here.

The first is to provide the correct eln destination directory during the
build so it can be used correctly by the logic that starts at
loadup.el:452.  This should fixup the filenames so afterwards when
resurrecting the logic in pdumper.c can work correctly.

About this there's a branch in feature/native-comp-macos-fixes (by
Vibhav Pant Cc'ed) with a fix.  See also [1].  Maybe you like to give it
a go.

The other possible source of problems may be Vinvocation_directory still
not set when we pass into pdumper.c:5270, I can't verify that as I don't
have use macos but should be realitively easy to verify.

Ciao

  Andrea

[1] <https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00700.html>