From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andreas Fuchs Newsgroups: gmane.emacs.bugs Subject: bug#43137: 28.0.50; [feature/native-comp] .eln path fixup confused using relative paths Date: Mon, 31 Aug 2020 11:11:34 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003a079805ae2dd245" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8722"; mail-complaints-to="usenet@ciao.gmane.io" To: 43137@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 31 17:13:13 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kClUe-00028V-Ku for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 17:13:12 +0200 Original-Received: from localhost ([::1]:42944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kClUd-0006Jh-KY for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 11:13:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46828) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kClUV-0006HJ-36 for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 11:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41803) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kClUU-0006RP-N1 for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 11:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kClUU-0003NO-HP for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 11:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andreas Fuchs Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2020 15:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 43137 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.159888673312913 (code B ref -1); Mon, 31 Aug 2020 15:13:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 31 Aug 2020 15:12:13 +0000 Original-Received: from localhost ([127.0.0.1]:53347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kClTS-0003Lf-7Z for submit@debbugs.gnu.org; Mon, 31 Aug 2020 11:12:13 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:45116) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kClTN-0003LU-Ly for submit@debbugs.gnu.org; Mon, 31 Aug 2020 11:11:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kClTN-0003yA-E8 for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 11:11:53 -0400 Original-Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:38576) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kClTK-0006J5-Qf for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 11:11:53 -0400 Original-Received: by mail-ed1-x52e.google.com with SMTP id c8so2154857edv.5 for ; Mon, 31 Aug 2020 08:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boinkor-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=GDuB5xjOYrP/4PdUwW5Xm+AmoMBZ9zWi3OOD2RIjvGQ=; b=tKLgEQY+yFkznnbqhg1b9mwggd7F9VOSzaVO5Bgexz6/8Lp7pfnfKcmz69eAY9Ws55 LRvfvFpKCDI3GpDdc7IjOkql8w3WWlCKO/lgXA8dsfJ+9RVjImwZCqElbu4gcSMzTi5W FN3m/+al0hz8gdNORub94EaWmbaKc8GStzwA2KAe0hTZEc4r0u2fPUuq8uP/CcM2UTy9 73HXkTgLbG84mAD8/xhAex4vCKEvXHciBi3Nc7dBMQD6AHjB+o3W3su/kBZLzM3lxk2w iFBzI+ShfVJ7znUwOeA2TV+h/9DRi392cgSZ90lkE4F8/o3PCQ2SJbNCXa7WobjRhTob sD7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GDuB5xjOYrP/4PdUwW5Xm+AmoMBZ9zWi3OOD2RIjvGQ=; b=FoLpkFdBhp+YEoDArwokgF6N2rpZQeD9bWWoFUAUHESZE5DNJv1wsy4itobBMGC2J0 q3U8e79lV2ZHkNAVBZJYS9NOrj6dJs4kDCYQ3GZqeugwSV192V4gdNdcLXr1gXQN7cqd wceKu2PDxr3kW4rlL+3XLbDjM2mctdnQF/3Kbf6yelO+5QWj5QdZHYsn0mi5w4+8szeI WvidOSRe39nlj59T7Ji3CBNQEeJfY6xu8KoI7ErCrBZEkEN3lq6OPKmgGMm/MhdwkdB7 M9B5shpiu3QSGAiyizblECk7Yg6mhoaCqrIz+r72vghpo6oM1PVRW1s8CD8+T8NrVr0a NOAQ== X-Gm-Message-State: AOAM531/cG/Jcnh3SD9KpyF3N35uniInTaiZ58Ja9v6AaUNgcHXvRQ5R MW+LWvH8/jEaj/+UjHQ60VhgaNjL9TdHd87R70vIkC3lJVejeGNd X-Google-Smtp-Source: ABdhPJznzdbvrXTEExxvlpWkX9oraRkQgLLRvUlhasYaNVqHLxxz5LfkR+bHSj5z7Ti8S10NWZVRERikXJITMKIDZXI= X-Received: by 2002:a05:6402:847:: with SMTP id b7mr1738015edz.39.1598886707327; Mon, 31 Aug 2020 08:11:47 -0700 (PDT) Received-SPF: none client-ip=2a00:1450:4864:20::52e; envelope-from=asf@boinkor.net; helo=mail-ed1-x52e.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:186774 Archived-At: --0000000000003a079805ae2dd245 Content-Type: text/plain; charset="UTF-8" On macos (if you use --with-ns), there are two ways the emacs binary gets installed: * as /bin/emacs, as normal * as /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 --0000000000003a079805ae2dd245 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On macos (if you use --with-ns), there are two way= s the emacs binary
gets installed:

* as <prefix>/bin/emacs,= as normal
* as <prefix>/Application/Emacs.app/Contents/MacOS/Emac= s, in a macOS app
=C2=A0 bundle.

Both of these cause problems, un= fortunately:

The "normal" emacs binary you can't invok= e from $PATH:

$ emacs -q --batch --eval '(message "hi"= )'
emacs: dlopen(../eln-cache/x86_64-apple-darwin19.6.0-9cab85d51a86= 56a0/lisp-mode-0189ba85598c041b7504f0a916c04219-5bf5ce8701bca2b361b97967a6f= 95776.eln, 1): image not found

But it does work when run with an abs= olute 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 t= he relative path
at all either:

$ /nix/store/a55i9aws0j96z0zfzxff= fmfb6k2lw53v-emacs-gcc-20200814.0/Applications/Emacs.app/Contents/MacOS/Ema= cs
emacs: dlopen(/nix/store/a55i9aws0j96z0zfzxfffmfb6k2lw53v-emacs-gcc-2= 0200814.0/Applications/Emacs.app/Contents/MacOS/../eln-cache/x86_64-apple-d= arwin19.6.0-9cab85d51a8656a0/lisp-mode-0189ba85598c041b7504f0a916c04219-5bf= 5ce8701bca2b361b97967a6f95776.eln, 1): image not found
=C2=A0
I have = traced both of these down to the relocation logic in pdumper.c:
https://github.com/emacs-mirror/emacs/blob/feature/nativ= e-comp/src/pdumper.c#L5255-L5277

This code (and the correspondin= g 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 director= ies that then fail to work. That the plain "emacs"
binary fail= s 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 sto= re, so
there's a very fixed pathname that everything lives at foreve= r; is
it possible to turn off that pathname relativization?

Alter= natively, I guess for darwin I'd also be good if we could get the
co= rrect relative names in the application bundle; There is just one
`../Re= sources` too few in there. I think to handle this right, we'd have
t= o add another case to the installation_state enum in pdumper.c, is
that = right?

Cheers,
Andreas.



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

Con= figured using:
=C2=A0'configure --prefix=3D/nix/store/a55i9aws0j96z0= zfzxfffmfb6k2lw53v-emacs-gcc-20200814.0 --disable-build-details --with-modu= les --with-ns --disable-ns-self-contained --with-nativecomp CFLAGS=3D-DMAC_= OS_X_VERSION_MAX_ALLOWED=3D101200'


--
Andreas Fuchs, (htt= p://|im:asf@|mailto:asf@)boinkor.net, antifuchs
--0000000000003a079805ae2dd245--