all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Ken Brown <kbrown@cornell.edu>
Cc: 52376@debbugs.gnu.org, bhavin7392@gmail.com, akrl@sdf.org
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	[thread overview]
Message-ID: <83a6h7qpal.fsf@gnu.org> (raw)
In-Reply-To: <4a25c242-e926-a0f1-7b2c-d5c15259e9d7@cornell.edu> (message from Ken Brown on Fri, 10 Dec 2021 14:53:30 -0500)

> Date: Fri, 10 Dec 2021 14:53:30 -0500
> Cc: 52376@debbugs.gnu.org, akrl@sdf.org
> From: Ken Brown <kbrown@cornell.edu>
> 
> 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?





  reply	other threads:[~2021-12-11 12:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-08 17:21 bug#52376: 28.0.90; libdir is missing from native-comp-eln-load-path with GTK3 build Bhavin Gandhi
2021-12-08 17:33 ` Eli Zaretskii
2021-12-08 18:05   ` Bhavin Gandhi
2021-12-08 18:25     ` Eli Zaretskii
2021-12-08 19:19       ` Bhavin Gandhi
2021-12-08 20:11         ` Eli Zaretskii
2021-12-08 20:31           ` Bhavin Gandhi
2021-12-09 11:06           ` Andrea Corallo
2021-12-09 17:09             ` Bhavin Gandhi
2021-12-09 17:23               ` Andrea Corallo
2021-12-09 18:29                 ` Bhavin Gandhi
2021-12-09 20:14                   ` Andrea Corallo
2021-12-09 20:18                     ` Andrea Corallo
2021-12-10  9:25                       ` Bhavin Gandhi
2021-12-10  9:45                         ` Andrea Corallo
2021-12-10 10:00                           ` Bhavin Gandhi
2021-12-10 11:36                             ` Eli Zaretskii
2021-12-10 11:51                               ` Bhavin Gandhi
2021-12-10 12:20                                 ` Eli Zaretskii
2021-12-10 14:38                                   ` Bhavin Gandhi
2021-12-10 14:50                                     ` Eli Zaretskii
2021-12-10 15:08                                       ` Eli Zaretskii
2021-12-10 15:47                                         ` Bhavin Gandhi
2021-12-10 16:56                                           ` Eli Zaretskii
2021-12-10 19:53                                             ` Ken Brown
2021-12-11 12:49                                               ` Eli Zaretskii [this message]
2022-01-01 17:12                                             ` Bhavin Gandhi
2022-01-01 17:26                                               ` Ken Brown
2022-01-02 17:33                                                 ` Bhavin Gandhi
2022-01-01 17:27                                               ` Eli Zaretskii
2022-01-01 19:04                                                 ` Bhavin Gandhi
2022-01-01 19:19                                                   ` Eli Zaretskii
2022-01-02 17:39                                                     ` Bhavin Gandhi
2022-01-02 18:22                                                       ` Eli Zaretskii
2022-01-04 18:17                                                         ` Bhavin Gandhi
2022-01-04 20:07                                                           ` Eli Zaretskii
2021-12-10 11:32                           ` Eli Zaretskii
2021-12-09 18:39                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a6h7qpal.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=52376@debbugs.gnu.org \
    --cc=akrl@sdf.org \
    --cc=bhavin7392@gmail.com \
    --cc=kbrown@cornell.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.