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.devel Subject: Re: Finding the dump (redux) Date: Sat, 17 Apr 2021 21:45:12 +0300 Message-ID: <83k0p0vjgn.fsf@gnu.org> References: <5decf0e7-8f26-3fc7-7094-1bfdb211eefc@emvision.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2476"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Ali Bahrami Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 17 20:47:02 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lXpyA-0000VA-Gf for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Apr 2021 20:47:02 +0200 Original-Received: from localhost ([::1]:33354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXpy9-0007y0-KC for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Apr 2021 14:47:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXpwg-0007BW-3Y for emacs-devel@gnu.org; Sat, 17 Apr 2021 14:45:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38309) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXpwf-0007Vu-1f; Sat, 17 Apr 2021 14:45:29 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4439 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lXpwd-0003G5-MY; Sat, 17 Apr 2021 14:45:28 -0400 In-Reply-To: <5decf0e7-8f26-3fc7-7094-1bfdb211eefc@emvision.com> (message from Ali Bahrami on Thu, 15 Apr 2021 13:38:37 -0600) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268135 Archived-At: > From: Ali Bahrami > Date: Thu, 15 Apr 2021 13:38:37 -0600 > > % cd /usr/bin > % ls -alFh emacs* > lrwxrwxrwx 1 root root 9 Apr 14 22:15 emacs -> emacs-gtk* > -r-xr-xr-x 2 root bin 7.05M Apr 14 22:15 emacs-gtk* > -r-xr-xr-x 2 root bin 7.05M Apr 14 22:15 emacs-gtk-27.2* > -r-xr-xr-x 2 root bin 6.09M Apr 14 22:15 emacs-nox* > -r-xr-xr-x 2 root bin 6.09M Apr 14 22:15 emacs-nox-27.2* > -r-xr-xr-x 2 root bin 7.07M Apr 14 22:15 emacs-x* > -r-xr-xr-x 2 root bin 7.07M Apr 14 22:15 emacs-x-27.2* > -r-xr-xr-x 1 root bin 47K Apr 14 22:15 emacsclient* > > And the pdmp files are similarly named, to match the > emacs executables: > > % cd /usr/lib/emacs/27.2/x86_64-pc-solaris2.11 > % ls -alhF *.pdmp > -r--r--r-- 2 root bin 10.2M Apr 14 22:15 emacs-gtk-27.2.pdmp > -r--r--r-- 2 root bin 10.2M Apr 14 22:15 emacs-gtk.pdmp > -r--r--r-- 2 root bin 9.64M Apr 14 22:15 emacs-nox-27.2.pdmp > -r--r--r-- 2 root bin 9.64M Apr 14 22:15 emacs-nox.pdmp > -r--r--r-- 2 root bin 10.1M Apr 14 22:15 emacs-x-27.2.pdmp > -r--r--r-- 2 root bin 10.1M Apr 14 22:15 emacs-x.pdmp > > As noted, the default is emacs-gtk, but I can change that: > > # pkg set-mediator -I emacs-x emacs > <...pkg output elided...> > # ls -alFh /usr/bin/emacs > rwxrwxrwx 1 root root 7 Apr 15 11:47 /usr/bin/emacs -> emacs-x* > > Like a lot of GNU/Linux distributions, we used to use a > shell script for this, but we moved to the mediator years > ago. With the new emacs, this works well for the explicitly > named versions (emacs-gtk, emacs-nox, and emacs-x). But, when > run via the 'emacs' symlink (the usual case), the binary is > unable to find its pdmp file. It still runs, but ends up > loading all the separate elc files, which is undesirable. > > I can solve this without changing emacs, superficially, by just > adding a corresponding mediator symlink for emacs.pdmp in the > PATH_EXEC directory. But then, if an end user were to make their > own symlink to one of these emacs variants, they'll still face > this problem: > > % ln -s /usr/bin/emacs-gtk ~/bin/myemacs Why can't you put the *.pdmp files in the same directory where you keep the emacs-* executables (/usr/bin, AFAIU)? That is already supported by the current code, I think. > Sure, that user could specify the pdmp file on the command > line, or wrap it in a shell script, but for default behavior, > I don't think that should be necessary. Why shouldn't an emacs, > found by whatever path, not be able to find its default pdmp file > in PATH_EXEC? I believe that the search done by emacs is just > missing a check that would solve this. The problem is that > load_pdump() in src/emacs.c only searches PATH_EXEC for > emacs.pdmp, and then for the pdmp file with the name given by: > > basename(argv[0]) > > If it were to also search for > > basename(realpath(argv[0])) > > then it would find pdmp files that match either the given, or > "absolute" names, rather than just the given name, and symlinks > that point at emacs executables would always find the default > pdmp file that goes with them, whether we deliver them, or the > user makes their own. But realpath(argv[0]) can produce to a file in another directory, because realpath expands all the symlinks, not just that of the basename. Does it make sense to look up the .pdmp file in the directory of the original argv[0] when it is a symlink? > - Move the repeated code into functions, to clean up load_pdump(). > > - Save the basename from the result of calling realpath() during the > search of the executable directory. > > - During the PATH_EXEC stage, use the saved realpath basename to > add a check for that name. This is not enough, if we want to support *.pdmp files that have arbitrary names. For example, when Emacs is invoked as "../emacs" (or any other relative file name which includes slashes), we currently don't expand symlinks, so with your proposal "emacs" and "../emacs" will behave differently. IOW, supporting arbitrarily-named *.pdmp files requires more thorough revision of the logic in load_pdump than just some simple refactoring. Especially as Emacs 28 will have the native-compilation feature, whereby it also needs to find at startup the directory with the *.eln files that correspond to the preloaded Lisp files; see bug#44128.