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#52376: 28.0.90; libdir is missing from native-comp-eln-load-path with GTK3 build Date: Sat, 11 Dec 2021 14:49:54 +0200 Message-ID: <83a6h7qpal.fsf@gnu.org> References: <838rwvvtqs.fsf@gnu.org> <83zgpavoui.fsf@gnu.org> <83sfv0sncm.fsf@gnu.org> <83pmq4slb6.fsf@gnu.org> <83k0gcsee9.fsf@gnu.org> <83h7bgsdk0.fsf@gnu.org> <83czm4s8ke.fsf@gnu.org> <4a25c242-e926-a0f1-7b2c-d5c15259e9d7@cornell.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13058"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52376@debbugs.gnu.org, bhavin7392@gmail.com, akrl@sdf.org To: Ken Brown Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Dec 11 13:53:25 2021 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 1mw1sT-0003Eq-7s for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 13:53:25 +0100 Original-Received: from localhost ([::1]:36872 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mw1sS-0004UD-5x for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 11 Dec 2021 07:53:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw1qA-0001jE-EM for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 07:51:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37178) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mw1q9-00083R-Tg for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 07:51:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mw1q9-00049b-N5 for bug-gnu-emacs@gnu.org; Sat, 11 Dec 2021 07:51:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Dec 2021 12:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52376 X-GNU-PR-Package: emacs Original-Received: via spool by 52376-submit@debbugs.gnu.org id=B52376.163922701915914 (code B ref 52376); Sat, 11 Dec 2021 12:51:01 +0000 Original-Received: (at 52376) by debbugs.gnu.org; 11 Dec 2021 12:50:19 +0000 Original-Received: from localhost ([127.0.0.1]:48724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw1pS-00048c-Kc for submit@debbugs.gnu.org; Sat, 11 Dec 2021 07:50:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mw1pQ-00048N-EG for 52376@debbugs.gnu.org; Sat, 11 Dec 2021 07:50:17 -0500 Original-Received: from [2001:470:142:3::e] (port=58674 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw1pI-0007gs-Sm; Sat, 11 Dec 2021 07:50:08 -0500 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=k129CgGuTbFNrtQnXUBnQWE5nHLq7IgXaV9uT9U4hbc=; b=SSGPgplgyfGc AeAKv2VvH45rnigNbDNpNYNzOcyLnJVNDjP4AA+kulSpD2J5ryuJs4CjMKFqR6s3JxvcFKP+9/g4O 34o2SmJXPM4OTPQo56VGsZ+UdDlthBbEg1uAq2RLjozGHpLscie+yQkwiZJm9ZqqQ2e00mEAJZBXa jHj1Rp4CDcwyTXzwuMtHL7+UbvrdQvokqhNSgJktzCcKSi0OrXALVDuOM1fnNR4gSi77Pi2jDD6xb VWBteKtVa4QYkO2FZnflHWjsY2qD3rhgsDXb2sq+6Y7A0dvKUBfpPAqvEYdSCN4GHpH4/Ep5JG0rd gHCYN7owoc5L5ZS2H/uMLA==; Original-Received: from [87.69.77.57] (port=4293 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mw1pF-0005vG-Od; Sat, 11 Dec 2021 07:50:08 -0500 In-Reply-To: <4a25c242-e926-a0f1-7b2c-d5c15259e9d7@cornell.edu> (message from Ken Brown on Fri, 10 Dec 2021 14:53:30 -0500) 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:222114 Archived-At: > Date: Fri, 10 Dec 2021 14:53:30 -0500 > Cc: 52376@debbugs.gnu.org, akrl@sdf.org > From: Ken Brown > > On 12/10/2021 11:56 AM, Eli Zaretskii wrote: > > Please reconsider. When Emacs finds the .pdmp file near its > > executable, it makes certain assumptions about the location of the > > *.eln files that don't fit the installed Emacs. So placing the .pdmp > > files there is not a good idea. > > Could you elaborate on what problems this causes? I've been doing something > similar in my Cygwin builds, and I'm not aware of any problems. But maybe I > just haven't noticed. Here's what I have, with three versions of emacs installed: Look at the logic in pdumper.c: /* Check just once if this is a local build or Emacs was installed. */ /* Can't use expand-file-name here, because we are too early in the startup, and we will crash at least on WINDOWSNT. */ if (installation_state == UNKNOWN) { eln_fname = make_uninit_string (execdir_len + fn1_len); fndata = SSDATA (eln_fname); memcpy (fndata, emacs_execdir, execdir_len); memcpy (fndata + execdir_len, SSDATA (cu_file1), fn1_len); if (file_access_p (fndata, F_OK)) installation_state = INSTALLED; else { eln_fname = make_uninit_string (execdir_len + fn2_len); fndata = SSDATA (eln_fname); memcpy (fndata, emacs_execdir, execdir_len); memcpy (fndata + execdir_len, SSDATA (cu_file2), fn2_len); installation_state = LOCAL_BUILD; } fixup_eln_load_path (eln_fname); } It decides whether this is an installed or an uninstalled Emacs according to whether it can access the .eln file under the first or the second candidate directory. If you are careful enough to use real /usr/bin and /usr/lib directories, this will work. But if /usr/bin/emacs is a symlink, and there's no real /usr/lib directory to go with it, the logic shown about can easily fail. This logic was generally designed to handle the "normal" case, where the pdumper file is under /usr/libexec; the case where it is near the Emacs binary is typically when you run Emacs uninstalled. It does attempt to handle several alternative use cases, but not every possible one of them. And the logic is tricky enough so I tend to forget its details all the time, and need to read the code again... So caveat emptor. Why don't you configure each Emacs build with a different libexecdir instead?