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

[Andreas Fuchs <asf@boinkor.net>]

[-- Attachment #1: Type: text/plain, Size: 2864 bytes --]

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.



In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60
Version 10.15.6 (Build 19G2021))
Repository revision: aa526c9470d679e9144af55d9e56928a111d2ceb
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.6

Configured using:
 'configure
--prefix=/nix/store/a55i9aws0j96z0zfzxfffmfb6k2lw53v-emacs-gcc-20200814.0
--disable-build-details --with-modules --with-ns
--disable-ns-self-contained --with-nativecomp
CFLAGS=-DMAC_OS_X_VERSION_MAX_ALLOWED=101200'


--
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

[-- Attachment #2: Type: text/html, Size: 3460 bytes --]