emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43137: closed (28.0.50; [feature/native-comp] .eln path fixup confus


From: GNU bug Tracking System
Subject: bug#43137: closed (28.0.50; [feature/native-comp] .eln path fixup confused using relative paths)
Date: Fri, 02 Oct 2020 08:00:02 +0000

Your message dated Fri, 02 Oct 2020 07:59:53 +0000
with message-id <xjfr1qhukg6.fsf@sdf.org>
and subject line Re: bug#43137: 28.0.50; [feature/native-comp] .eln path fixup 
confused using relative paths
has caused the debbugs.gnu.org bug report #43137,
regarding 28.0.50; [feature/native-comp] .eln path fixup confused using 
relative paths
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
43137: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43137
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.0.50; [feature/native-comp] .eln path fixup confused using relative paths Date: Mon, 31 Aug 2020 11:11:34 -0400


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

--- End Message ---
--- Begin Message --- Subject: Re: bug#43137: 28.0.50; [feature/native-comp] .eln path fixup confused using relative paths Date: Fri, 02 Oct 2020 07:59:53 +0000 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Hi Andreas,
>
> I think
> "dc0cf16c7a Always set 'Vexec_path' before 'Vinvocation_directory' 
> (bug#43137)"
> should fix the issue.  Could you have a look if it works for you?
>

I'm closing this as I believe this is solved.  Please follow-up if some
problem shows-up so we can repoen it.

Thanks

  Andrea


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]