From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 16:32:01 +0000 Message-ID: References: Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23818"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: 43137@debbugs.gnu.org, Vibhav Pant To: Andreas Fuchs Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 31 18:44:09 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 1kCmue-00064x-Au for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 18:44:08 +0200 Original-Received: from localhost ([::1]:37528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCmud-0002rC-B4 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 31 Aug 2020 12:44:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40396) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCmju-0000wD-Mv for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 12:33:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41973) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kCmju-0000pc-Cb for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 12:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kCmju-0005NS-9K for bug-gnu-emacs@gnu.org; Mon, 31 Aug 2020 12:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 31 Aug 2020 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43137 X-GNU-PR-Package: emacs Original-Received: via spool by 43137-submit@debbugs.gnu.org id=B43137.159889152920608 (code B ref 43137); Mon, 31 Aug 2020 16:33:02 +0000 Original-Received: (at 43137) by debbugs.gnu.org; 31 Aug 2020 16:32:09 +0000 Original-Received: from localhost ([127.0.0.1]:53519 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCmj3-0005MK-E8 for submit@debbugs.gnu.org; Mon, 31 Aug 2020 12:32:09 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:52792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kCmiy-0005M7-S7 for 43137@debbugs.gnu.org; Mon, 31 Aug 2020 12:32:08 -0400 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTP id 07VGW1vN012721; Mon, 31 Aug 2020 16:32:02 GMT In-Reply-To: (Andreas Fuchs's message of "Mon, 31 Aug 2020 11:11:34 -0400") 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:186777 Archived-At: Andreas Fuchs writes: > 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 > =C2=A0 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-5bf5ce8701bca2b361b97967a6f957= 76.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-5bf5ce8701bca2b361b97967a6f957= 76.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/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]