From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73318: 31.0.50; with-native-compilation=aot breaks exec -a emacs Date: Fri, 04 Oct 2024 16:57:47 +0300 Message-ID: <86iku8x95w.fsf@gnu.org> References: <864j6eb29f.fsf@gnu.org> <861q1iayk6.fsf@gnu.org> <86wmja9iwi.fsf@gnu.org> <86plp19kei.fsf@gnu.org> <86ldz4xc93.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30774"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73318@debbugs.gnu.org, larsi@gnus.org, acorallo@gnu.org, schwab@linux-m68k.org, shipmints@gmail.com To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 04 15:59:23 2024 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 1swiq2-0007nB-Er for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 04 Oct 2024 15:59:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swipg-0002bu-V8; Fri, 04 Oct 2024 09:59:00 -0400 Original-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 1swipe-0002bg-Uq for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 09:58:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1swipe-000824-Mr for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 09:58:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=V4y2pw46zyJgFilSft3vjQ++rHlot3inKkGsg94u+dQ=; b=g1/ImGyctE6KZfRjbUUng/ufTxDVRkhg5KIEv1tSLQFWNqCKvJOGMxSvPKE7Rcnm3BHe5S23joOFxqiG0cE2P+2tdZxGrgHE9ml9rmUw1mv4qwhjoML3LL8dC4N3pxyvKUcssgf/L/sL74Vop8YFh4Ivh/62MJjy44msWjFKHIeAHtqZqGHbPN/A4C7ugcOigvGNy71KM/ZTQ2AjqpsVyx1g4/nqpRXrtkhJZyQoodl5emDtHiIIMnvd6zSBqTEMZn9UJDrBDBqPfIEwouT2W/hKyjQzINTracjToEE4ychP1Rne7Rt15nINKHERM8TBYjpotzDg7Wet37FnNF88Dg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swiph-0007kT-SR for bug-gnu-emacs@gnu.org; Fri, 04 Oct 2024 09:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Oct 2024 13:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73318 X-GNU-PR-Package: emacs Original-Received: via spool by 73318-submit@debbugs.gnu.org id=B73318.172805030929735 (code B ref 73318); Fri, 04 Oct 2024 13:59:01 +0000 Original-Received: (at 73318) by debbugs.gnu.org; 4 Oct 2024 13:58:29 +0000 Original-Received: from localhost ([127.0.0.1]:36153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swipA-0007jW-Q7 for submit@debbugs.gnu.org; Fri, 04 Oct 2024 09:58:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swip9-0007jI-9a for 73318@debbugs.gnu.org; Fri, 04 Oct 2024 09:58:28 -0400 Original-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 1swioz-0007xj-Sw; Fri, 04 Oct 2024 09:58:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=V4y2pw46zyJgFilSft3vjQ++rHlot3inKkGsg94u+dQ=; b=jrJu/xX9idLy 3IdHU/9UugcUMxW4DDJ4N5HLXR5gjOg+vlrl5NCFEcveok3/mk//UL+MI8oETGsoqSgQe6Wx3xujf +XT2gCwyPLBHJW7Q6mMUejelEEGhxfsz0LMnwgs729zNY40s5r5oSa/edG8IvG5ss1vYUU2NgyLqa 07HKe5z+6bvnHRhH9vHwDuvs0MUAbKBqGgwa5USuPaOIAnNvbj6b1NYhtRQRtifNHqTlemtP1QbYq lI2GattbeImG2vW3TmWdUnpy4ZD94HcDeTUWrmpzgOymJVVHVNQYFYBFZd6LsgbgGpyWp2CxMyNRc kUq9yL4P/MxDkblvx6iLmQ==; In-Reply-To: (message from Spencer Baugh on Fri, 04 Oct 2024 09:22:08 -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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292965 Archived-At: > From: Spencer Baugh > Cc: 73318@debbugs.gnu.org, larsi@gnus.org, acorallo@gnu.org, > schwab@linux-m68k.org, shipmints@gmail.com > Date: Fri, 04 Oct 2024 09:22:08 -0400 > > > The specific issue with finding the pdumper file more reliably is > > solved in Emacs 30 in the way Andreas suggested, but it has no effect > > on the problem which you describe, with finding the preloaded *.eln > > files. > > Ah, interesting. So Emacs 30 falls back on looking up the pdmp in > PATH_EXEC, a path compiled into the Emacs binary. > > Should we perhaps do the same for the native-lisp directory? We already do, sort of. We just rely on the search for the pdumper file to supply us with the answer. See below. > If we can't find it in other ways, look it up relative to a path > compiled into the Emacs binary? I don't know if that should be > PATH_EXEC or some other path. > > That would work on my system. Then we wouldn't need to use > /proc/self/exe at all. > > Might that be the best solution? It isn't that easy. We need to support 2 possible locations for the preloaded *.eln files: in the source tree and in the installation tree. You now want us to look in yet a third place. Take a look at dump_do_dump_relocation where we look for the *.eln files. What you suggest is to add a third place to that code. Currently, we infer where the *.eln files are by looking at the file name of the Emacs executable file. And your script violates this protocol by removing the leading directories from argv[0] and placing Emacs in a directory not on PATH. > >> > . what if /proc/self/exe is unreadable? AFAIK, on some systems you > >> > need special privileges to follow its symlink > >> > . what if /proc/self/exe points to a file name that is a symlink, or > >> > some of its leading directories are symlinks? > >> > . what if Emacs is invoked via a script which is in the correct > >> > installation directory, but the actual binary the script invokes > >> > is not in the expected location relative to the native-lisp/ > >> > directory where we have the preloaded *.eln files? > >> > > >> > The existing code handles all these cases, and some others. We could > >> > perhaps _add_ the use of /proc/self/exe to what we have, but we'd need > >> > to be sure that it doesn't break for the above situations. > > > > I'm still waiting for some answers to these. > > If we use /proc/self/exe, I'm fine with it being a fallback if all other > mechanisms fail. That should make these cases still work fine, right? To use /proc/self/exe as fallback, we need to somehow reject the Emacs "executable" found in your case. Because otherwise fallbacks are only used if the previous attempts fail, and the attempt to find atgv[0] along PATH does not fail in your case, it just finds the "wrong" file. > > Why cannot you modify the script for all the commands to include the > > leading directories in executable-name? That is all that is needed > > for Emacs to find its *.eln files. > > See the motivation that I quoted above: > > For context, I believe the reason why we pass `-a` is to make the prog > more identifiable when users try to find it in the output of > `ps`. That still sounds like the right thing to do in the majority of > the cases. > > Including the leading directories would make them show up in the output > of "ps", which is uglier. "Uglier" is in the eyes of the beholder. The important thing is that it solves the problem without any other changes, and will then use code which was tested and validated by many users. > I realize this might not seem like an important justification, but it > works for every other program we run, and has worked for decades. And > other distributors might be doing this too, so I think it's reasonable > to make Emacs robust to this by having it fall back to looking up > native-lisp in something like PATH_EXEC. I disagree that this is reasonable, and what you suggest is not possible/practical anyway. > But now I think we maybe don't need to use /proc/self/exe at all, and > can just have Emacs fall back on something like PATH_EXEC when it fails > to find the native lisp files. See above. If you insist to go this much more complicated way, we'll need to modify the code in dump_do_dump_relocation to use PATH_EXEC, and deal with possible false positives.