From unknown Thu Aug 14 22:21:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79064: native-lisp directory resolution =?UTF-8?Q?shouldn=E2=80=99t?= depend on Emacs filename resolution via argv[0] Resent-From: Liam Hupfer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jul 2025 04:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 79064 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 79064@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17530723237899 (code B ref -1); Mon, 21 Jul 2025 04:33:02 +0000 Received: (at submit) by debbugs.gnu.org; 21 Jul 2025 04:32:03 +0000 Received: from localhost ([127.0.0.1]:54249 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1udiC2-00023J-Ek for submit@debbugs.gnu.org; Mon, 21 Jul 2025 00:32:02 -0400 Received: from lists.gnu.org ([2001:470:142::17]:50504) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1udiBx-000220-NF for submit@debbugs.gnu.org; Mon, 21 Jul 2025 00:32:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1udiB8-0007VV-HX for bug-gnu-emacs@gnu.org; Mon, 21 Jul 2025 00:31:23 -0400 Received: from out-170.mta1.migadu.com ([2001:41d0:203:375::aa]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1udiB4-0004i7-F5 for bug-gnu-emacs@gnu.org; Mon, 21 Jul 2025 00:31:05 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpfr.net; s=key1; t=1753072258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=LYXjHzDamHrDG5SgjDpfrFrr9o/dLtE7m5u4EyuRfuA=; b=RlKo1/3yxny6EhdTWSa3GojXrucHmKQ+Cw4w2frRLyRsRMLbGnrn/BehyppqgONd0k6Rhl eUJ+k04V0NOP6Svb8wuMGIzmKfcUqwOsFmAC3lQ+hvINxSanMc5l0leWy7wGxvjna38LRH 5zk7+PWUCbljnh9zou94vIyU4i4nCvzR6EKtoJT39SB+p98RDBmICNgMPvjG9GItDmtOx4 MMoCYIaz/qYjkisD+E4eRp7woCtHQoxpWPGv9p0jm/VMecWU9yBiaBDpfcGea2HlFmDObR n0FPS9k8ib01Nq4b6Ng1PVNgotg/A5MqNMy2Iht4LaFBtPwG4F/ukXO9XvDEjA== From: Liam Hupfer Date: Sun, 20 Jul 2025 23:30:44 -0500 Message-ID: <87h5z6p3m3.fsf@hpfr.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=2001:41d0:203:375::aa; envelope-from=liam@hpfr.net; helo=out-170.mta1.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, In find_emacs_executable, Emacs searches for its own executable based on argv[0]. If argv[0] has a slash in it, it assumes it is the path to the Emacs binary and makes it absolute. If not, it searches PATH for argv[0]. The resulting absolute filename is used to find the dump file, the native-lisp directory, and in kill-emacs to support restarting. In general, argv[0] can=E2=80=99t be relied upon to find the executable for= a process. It=E2=80=99s probably the best approach for the restarting case, a= nd there it=E2=80=99s not a big deal to just fail to restart if argv[0] is misleading. But application startup can=E2=80=99t depend on it resolving correctly. load_pdump has a hardcoded fallback based on PATH_EXEC which is built into the executable, but currently native-lisp resolution does not. Can we set up something similar there? Thanks! =E2=80=94Liam Context =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 This became a problem for me when I wrapped Emacs with a shell script called =E2=80=9Cemacs=E2=80=9D which sets some environment variables and ca= lls Emacs with =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 exec -a emacs "$emacs_path" "$@" =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 find_emacs_executable returns the path to the wrapper if it is on PATH. If it isn=E2=80=99t in the same directory as the Emacs binary, dump_do_dump_relocation will fail when it can=E2=80=99t find the native-lisp directory: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ emacs =E2=94=82 Error using execdir /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-e= macs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/: =E2=94=82 emacs: /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk= -wrapper-30.1-1.a05be41/bin/../native-lisp/30.1.90-f736b5c5/preloaded/windo= w.eln: cannot open shared object file: No such file or directory =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Wrappers like this are typical with package managers like Nix and Guix running on other Linux distributions, where it can be necessary to set variables like GDK_PIXBUF_MODULE_FILE and GIO_EXTRA_MODULES to ensure GTK applications like Emacs don=E2=80=99t use incompatible resources from t= he host GTK version. It=E2=80=99s possible to work around this by not using =E2=80=98exec -a=E2= =80=99 this way. But I=E2=80=99m opening the bug because Emacs should handle unpredictable argv[= 0] values robustly, regardless of my particular context. --=-=-=-- From unknown Thu Aug 14 22:21:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79064: native-lisp directory resolution =?UTF-8?Q?shouldn=E2=80=99t?= depend on Emacs filename resolution via argv[0] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Jul 2025 11:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79064 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Liam Hupfer Cc: 79064@debbugs.gnu.org Received: via spool by 79064-submit@debbugs.gnu.org id=B79064.17530979491727 (code B ref 79064); Mon, 21 Jul 2025 11:40:02 +0000 Received: (at 79064) by debbugs.gnu.org; 21 Jul 2025 11:39:09 +0000 Received: from localhost ([127.0.0.1]:55972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1udorN-0000Rn-3t for submit@debbugs.gnu.org; Mon, 21 Jul 2025 07:39:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46904) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1udorJ-0000Qy-Kp for 79064@debbugs.gnu.org; Mon, 21 Jul 2025 07:39:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1udorC-0001yM-UG; Mon, 21 Jul 2025 07:38:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=TU/bOGrmkTsgXGA88KPXazIsu3iWFZ6pj7JDhPYg2XU=; b=T5oCxftXZVmqRreOclds C2vvXKzSKvZofgZi82qbO34uY5aMV2DigFO3S+OtTOR8VOkawJfZITc3WGHtsy4CXxSXhwuxAWWXc r0RuYLeTUdEMgNtXJ38wxEnEpvEZSBEHKfB1RyzWS322dDHx1vxn4cqdaBfssCkBar9hiwIIjJVAU 1rbE3elzDG8ksxazbHlFzNVWcLhAWBzL2OkaZTmKgD7N3r4OC+ramqLGVEKz1DPketboPZ6+ZbLhz a8LTrqm1QD44mNGjeUavEefv1RbuLNXrcxtHUE/atQzqXOzIocYMokhK60K4BUGAUYPpoO71E+3Zg 91TxdPS7qFIOiQ==; Date: Mon, 21 Jul 2025 14:38:55 +0300 Message-Id: <8634apdb8w.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87h5z6p3m3.fsf@hpfr.net> (message from Liam Hupfer on Sun, 20 Jul 2025 23:30:44 -0500) References: <87h5z6p3m3.fsf@hpfr.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Liam Hupfer > Date: Sun, 20 Jul 2025 23:30:44 -0500 > > In find_emacs_executable, Emacs searches for its own executable based on > argv[0]. If argv[0] has a slash in it, it assumes it is the path to the > Emacs binary and makes it absolute. If not, it searches PATH for > argv[0]. The resulting absolute filename is used to find the dump file, > the native-lisp directory, and in kill-emacs to support restarting. > > In general, argv[0] can’t be relied upon to find the executable for a > process. It’s probably the best approach for the restarting case, and > there it’s not a big deal to just fail to restart if argv[0] is > misleading. But application startup can’t depend on it resolving > correctly. load_pdump has a hardcoded fallback based on PATH_EXEC which > is built into the executable, but currently native-lisp resolution does > not. Can we set up something similar there? > > Thanks! > > —Liam > > > Context > ═══════ > > This became a problem for me when I wrapped Emacs with a shell script > called “emacs” which sets some environment variables and calls Emacs > with > > ┌──── > │ exec -a emacs "$emacs_path" "$@" > └──── > > find_emacs_executable returns the path to the wrapper if it is on PATH. > If it isn’t in the same directory as the Emacs binary, > dump_do_dump_relocation will fail when it can’t find the native-lisp > directory: > > ┌──── > │ $ emacs > │ Error using execdir /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/: > │ emacs: /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/../native-lisp/30.1.90-f736b5c5/preloaded/window.eln: cannot open shared object file: No such file or directory > └──── > > Wrappers like this are typical with package managers like Nix and Guix > running on other Linux distributions, where it can be necessary to set > variables like GDK_PIXBUF_MODULE_FILE and GIO_EXTRA_MODULES to ensure > GTK applications like Emacs don’t use incompatible resources from the > host GTK version. > > It’s possible to work around this by not using ‘exec -a’ this way. But > I’m opening the bug because Emacs should handle unpredictable argv[0] > values robustly, regardless of my particular context. I'm extremely reluctant to make significant changes in that tricky and complex code, just to support this use case, which has other solutions. It took us quite a few iterations to get to where we are now, and the result supports several important situations with symlinks to the Emacs binary or to its directories, moving the entire Emacs installation tree, etc. It also supports several operating systems with vast;y different peculiarities. It is true that argv[0] is not 100% reliable, but we also don't rely just on it, we use several heuristics and fallbacks. (To answer your specific question: we don't use something similar to PATH_EXEC because the 30.1.90-f736b5c5 part of the directory name is computed dynamically during the late stages of the build, when the C sources were already compiled and linked.) >From where I stand, the expectation that Emacs startup code must support arbitrary tweaks in the "usual" installation scenario is unjustified. Package managers are respectfully requested to tweak their scripts to adapt to what Emacs requires, supports, and expects in this regard, because they (the package managers) are those which make these modifications in the "usual" installation directory structure in the first place. Sorry. From unknown Thu Aug 14 22:21:38 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79064: native-lisp directory resolution =?UTF-8?Q?shouldn=E2=80=99t?= depend on Emacs filename resolution via argv[0] Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 09 Aug 2025 12:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79064 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: liam@hpfr.net, 79064@debbugs.gnu.org Received: via spool by 79064-submit@debbugs.gnu.org id=B79064.175474081625870 (code B ref 79064); Sat, 09 Aug 2025 12:01:01 +0000 Received: (at 79064) by debbugs.gnu.org; 9 Aug 2025 12:00:16 +0000 Received: from localhost ([127.0.0.1]:40511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukiFE-0006j9-3p for submit@debbugs.gnu.org; Sat, 09 Aug 2025 08:00:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50802) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukiFB-0006fK-GF; Sat, 09 Aug 2025 08:00:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukiF5-0000Vw-FB; Sat, 09 Aug 2025 08:00:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=QBx0HgXzt1lJ3/YlNTn7oJ4tsy6SGEKby63BSq+rk4I=; b=fTaVxkwoXqXkP5UO+ox2 uef6KOx3V78MX8LZkcySHYTnBX6gTLDwxvrmoK1juZ9G/AsKLBdIadGuO9m8Ly/VKGtXPMa6OgoAN rUaNZlkikcNGquZM16iJVPVyWIoKM2tm3N8Kl/c/h9ag66GC967RjrtKMXJoy5fauKJLrcgtbolVK wr6V38CaEMXLmRUr6v+EDQH2KeCPEQSmH7IP5wh/492NEe18O9OY6qm7VTeFRjQIaDPOEZALMZg4N JQDZj+W153zTvs0dQzcnlio5QrIQKp04P+OslGo5hPaypEssQrbKmprEQIUG+IvzDcsDOly0sUnr6 /wlqoQgbOhPNHQ==; Date: Sat, 09 Aug 2025 15:00:02 +0300 Message-Id: <865xewn1rx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8634apdb8w.fsf@gnu.org> (message from Eli Zaretskii on Mon, 21 Jul 2025 14:38:55 +0300) References: <87h5z6p3m3.fsf@hpfr.net> <8634apdb8w.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 79064 wontfix close 79064 thanks > Cc: 79064@debbugs.gnu.org > Date: Mon, 21 Jul 2025 14:38:55 +0300 > From: Eli Zaretskii > > > From: Liam Hupfer > > Date: Sun, 20 Jul 2025 23:30:44 -0500 > > > > In find_emacs_executable, Emacs searches for its own executable based on > > argv[0]. If argv[0] has a slash in it, it assumes it is the path to the > > Emacs binary and makes it absolute. If not, it searches PATH for > > argv[0]. The resulting absolute filename is used to find the dump file, > > the native-lisp directory, and in kill-emacs to support restarting. > > > > In general, argv[0] can’t be relied upon to find the executable for a > > process. It’s probably the best approach for the restarting case, and > > there it’s not a big deal to just fail to restart if argv[0] is > > misleading. But application startup can’t depend on it resolving > > correctly. load_pdump has a hardcoded fallback based on PATH_EXEC which > > is built into the executable, but currently native-lisp resolution does > > not. Can we set up something similar there? > > > > Thanks! > > > > —Liam > > > > > > Context > > ═══════ > > > > This became a problem for me when I wrapped Emacs with a shell script > > called “emacs” which sets some environment variables and calls Emacs > > with > > > > ┌──── > > │ exec -a emacs "$emacs_path" "$@" > > └──── > > > > find_emacs_executable returns the path to the wrapper if it is on PATH. > > If it isn’t in the same directory as the Emacs binary, > > dump_do_dump_relocation will fail when it can’t find the native-lisp > > directory: > > > > ┌──── > > │ $ emacs > > │ Error using execdir /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/: > > │ emacs: /gnu/store/0jz32qbcibz6y5xzm6jwzh0x8kviy9gz-emacs-pgtk-gtk-wrapper-30.1-1.a05be41/bin/../native-lisp/30.1.90-f736b5c5/preloaded/window.eln: cannot open shared object file: No such file or directory > > └──── > > > > Wrappers like this are typical with package managers like Nix and Guix > > running on other Linux distributions, where it can be necessary to set > > variables like GDK_PIXBUF_MODULE_FILE and GIO_EXTRA_MODULES to ensure > > GTK applications like Emacs don’t use incompatible resources from the > > host GTK version. > > > > It’s possible to work around this by not using ‘exec -a’ this way. But > > I’m opening the bug because Emacs should handle unpredictable argv[0] > > values robustly, regardless of my particular context. > > I'm extremely reluctant to make significant changes in that tricky and > complex code, just to support this use case, which has other > solutions. It took us quite a few iterations to get to where we are > now, and the result supports several important situations with > symlinks to the Emacs binary or to its directories, moving the entire > Emacs installation tree, etc. It also supports several operating > systems with vast;y different peculiarities. > > It is true that argv[0] is not 100% reliable, but we also don't rely > just on it, we use several heuristics and fallbacks. > > (To answer your specific question: we don't use something similar to > PATH_EXEC because the 30.1.90-f736b5c5 part of the directory name is > computed dynamically during the late stages of the build, when the C > sources were already compiled and linked.) > > >From where I stand, the expectation that Emacs startup code must > support arbitrary tweaks in the "usual" installation scenario is > unjustified. Package managers are respectfully requested to tweak > their scripts to adapt to what Emacs requires, supports, and expects > in this regard, because they (the package managers) are those which > make these modifications in the "usual" installation directory > structure in the first place. > > Sorry. No further comments, so I'm now closing this bug.