From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Juan =?utf-8?Q?Jos=C3=A9_Garc=C3=ADa-Ripoll?= Newsgroups: gmane.emacs.devel Subject: Re: Avoid duplicate emacs.exe / emacs-$version.exe Date: Sat, 28 Mar 2020 21:41:51 +0100 Message-ID: <86y2rkb4a8.fsf@csic.es> References: <865zeoctg3.fsf@csic.es> <83v9mo5om8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="111578"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.90 (windows-nt) To: emacs-devel@gnu.org Cancel-Lock: sha1:tsyaDry+ctkcpKVZHuR3NP3DcoM= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 28 21:42:46 2020 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 1jIII0-000SuK-Vk for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Mar 2020 21:42:44 +0100 Original-Received: from localhost ([::1]:59816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIII0-0005jf-2T for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Mar 2020 16:42:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54235) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIIHL-0005Ju-1v for emacs-devel@gnu.org; Sat, 28 Mar 2020 16:42:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIIHJ-0008GS-Je for emacs-devel@gnu.org; Sat, 28 Mar 2020 16:42:02 -0400 Original-Received: from ciao.gmane.io ([159.69.161.202]:35798) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jIIHJ-0008F7-Db for emacs-devel@gnu.org; Sat, 28 Mar 2020 16:42:01 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1jIIHH-000S8E-84 for emacs-devel@gnu.org; Sat, 28 Mar 2020 21:41:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 159.69.161.202 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:245902 Archived-At: Eli Zaretskii writes: >> From: Juan José García-Ripoll >> >> Date: Sat, 28 Mar 2020 17:53:00 +0100 >> >> Right now in my hard disk I have two copies of statically linked Emacs. > > (This is a point, but Emacs is not linked statically, at least not by > default. The large size is mostly due to debug info, and you can > strip it if you want, although I don't recommend doing so for a > pretest version, because you cannot produce meaningful backtraces from > a stripped binary.) I am talking about the official archives *.zip, not the *.exe install file. I assumed "statically linked" because of the size and because of the dependencies they have been built against -- e.g. libpng, libtiff, etc.-- but from your message I deduce those libraries are loaded by Emacs only when available. > No, they don't waste space, at least not by default. When you install > Emacs, the installation procedure produces a hard link with another > name to the same file data. These two names are just 2 different > names that refer to the same disk space. [...] > This means your installation procedure is modified, or maybe you > installed a binary someone else produced, in which case the archive > used to package the binaries didn't support hard links. You can > restore the hard link by removing onhe of the copies and making a hard > link to the remaining copy under the other name. I am reporting figures that come from either (a) the official release from ftp.gnu.org, (b) the prerelease *.zip files from alpha.gnu.org and (c) the official build process as reported in emacs-27/nt. - For emacs 26.3, using Windows' explorer to unzip the *-no-deps.zip file creates two identical files, emacs.exe and emacs-26.3.exe. MSYS's "du" reports a total of 277Mb usage. Windows directory properties reports the same figure for "size" and "size occupied in disk" (apologies, my copy of Windows is in Spanish and I do not know what text is used in other locales) - Doing the same thing with a command line utility, unzip.exe, produces the same result. - For emacs 27.0.90, using Windows' explorer or unzip.exe to inflate the *-no-deps.zip creates two identical files, but this time 6Mb in size. Once more, both are two separate files, though now total space is just 13Mb (!) - Building from emacs-27 branch (Savannah's git), following the instructions from nt/ (i.e. configure + make install), creates two identical files, emacs.exe and emacs-27.0.90.exe. Space usage is as in 26.3, about 123Mb per executable. So I am using stock files, never my own copies. I am using also standard procedures. I do not understand why the executable sizes differ so much between release, prerelease and built from sources. However, there are no symbolic links happening at all. Indeed, MSYS's "ln" as used in the autoconf build process does not seem to work: it just copies the file. $ ln -sf foo faa $ cat faa Foo $ echo Faa > foo $ cat faa Foo My computer is an up-to-date Windows 10 (64-bit) installation using NTFS, btw. My versions of MSYS and Mingw64 are also pretty recent. So maybe you are discussing what happens in Linux or Mac systems? Cheers, -- Juan José García Ripoll http://juanjose.garciaripoll.com http://quinfog.hbar.es