From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.bugs Subject: bug#50666: 28.0.50; Fix native compilation on Cygwin Date: Thu, 23 Sep 2021 19:27:56 +0200 Organization: Linux Private Site Message-ID: <87h7ebrylf.fsf@Rainer.invalid> References: <9f20194e-b1ba-9417-4f18-caa1d80b5568@cornell.edu> <01a89ba6-2786-df04-0181-069b50a70331@cornell.edu> <835yux5dn1.fsf@gnu.org> <87bl4pf3s1.fsf@Otto.invalid> <83tuih3uvr.fsf@gnu.org> <877dfcg5tu.fsf@Otto.invalid> <83pmt44vn1.fsf@gnu.org> <83mto84r9l.fsf@gnu.org> <83fsu04mai.fsf@gnu.org> <1a5e01a2-2247-2f68-82f6-2075577e02b6@cornell.edu> <837dfc4hi1.fsf@gnu.org> <4ae8067f-55b2-d243-66f3-f76493095a39@cornell.edu> <83o88jvity.fsf@gnu.org> <8e8e74ce-0deb-bcdc-d298-be2e9d4636d7@cornell.edu> <83bl4juu2c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38593"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) To: 50666@debbugs.gnu.org Cancel-Lock: sha1:HNDP0u+5F5Hct0M1JrQIkw6utSI= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 23 19:33:57 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 1mTSbd-0009nP-8s for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Sep 2021 19:33:57 +0200 Original-Received: from localhost ([::1]:36816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTSbb-00005N-OS for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Sep 2021 13:33:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46550) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTSWs-0002DF-TU for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 13:29:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44229) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mTSWs-0003aC-Ju for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 13:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mTSWs-0008Kb-BX for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 13:29:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: <9f20194e-b1ba-9417-4f18-caa1d80b5568@cornell.edu> Resent-From: Achim Gratz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Sep 2021 17:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50666 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.163241809231959 (code B ref -1); Thu, 23 Sep 2021 17:29:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 23 Sep 2021 17:28:12 +0000 Original-Received: from localhost ([127.0.0.1]:55775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTSW4-0008JP-9G for submit@debbugs.gnu.org; Thu, 23 Sep 2021 13:28:12 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:57090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTSW2-0008JH-M8 for submit@debbugs.gnu.org; Thu, 23 Sep 2021 13:28:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46324) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTSW2-0000ls-C8 for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 13:28:10 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:49802) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTSVz-0002n7-UQ for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 13:28:10 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mTSVv-0001w9-PJ for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 19:28:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:215208 Archived-At: Eli Zaretskii writes: > What do you mean by "system libraries" here? Does it, for example, > include the DLLs distributed in the Cygwin port of libpng or libjpeg? > Or does that include only the basic libraries: the Cygwin DLL, the C > runtime, etc.? Any and all dynamic objects that have been properly installed by the Cygwin setup application will have their base addresses adjusted so that there will be no overlapping images. The rebase process tries to keep this space reasonably compact, if you really need to have the most compact address space you can trigger a full rebase. > If the only problem is with non-preloaded *.eln files, why not rebase > them on the fly, when they are loaded. That is, run the 'rebase' > command from the native-elisp-load function, before it actually loads > the file. User libraries are never loaded during startup, only when > some Lisp requires them. That might work. >> ...but it wouldn't eliminate the need for rebasing at each start for the reasons >> explained above. > > Perhaps that need could be eliminated after all, see above. The rebase would just happen at a different time, but I think it should be OK. > That's tough on users, because Emacs by default automatically compiles > every .el file it loads into .eln, if there's no up-to-date .eln file > already, and the compilation runs in the background (by forking > additional Emacs sub-processes that run in batch mode). In addition, > the native-compilation process sometimes decides that it needs to > create a special "trampoline" .eln file (if you want to know why, I'm > sure Andrea can explain) that correspond to parts of the *.el files. > The upshot is that users may not even be aware that new *.eln files > have been created as part of their session, and may not know their > names. Unless the automatic rebase process, which runs from > native-elisp-load, will also update the file in dynpath.d, I don't see > how users could maintain such a database by hand in practice. That's why Ken wants to ensure that the rebase is done directly after the creation of such files. We still need to rebase them again when the system address map changes. > There's one more aspect that you should be aware of. A single file > FOO.el could give birth to several different .eln files, for example > if they are compiled by different Emacs binaries and/or from different > source directories and/or from somewhat different versions of FOO.el. > For example, I now have 3 different versions of .eln files > corresponding to window.el, in the same directory: > > window-0d1b8b93-3370bedb.eln > window-0d1b8b93-7d08b7b4.eln > window-0d1b8b93-f8fc9683.eln > > This makes the job of maintaining the database by hand even harder and > more error-prone. I have been wondering about that, especially since the user might have the same home directory on different machines. That will be a major headache since we'll either need to find out which object belongs to which system (and have separate maps for each) or somehow ensure that the user rebase map is compatible with all systems the user works on. Skipping that part for now, all such objects must be the same architecture (i686-pc-cygwin / x86_64-pc-cygwin) and there should be some sort of architecture specific branches in the cache directory, which I seem to remember was already the case. Rebasing would then just treat every file in the current architecture branch as a separate object (and use up address space for each). Aside from the unfortunate proliferation of objects files (which each use up space in 64kByte blocks) it should still work however as long as there is never an object with the same name but different content. Trying to figure out which of these can actually be used in the same process would be too much and mostly wasted effort I'd think. > My point is that maybe we should make that decision already, before > burning too much time and energy on it. Maybe you should ask on the > Cygwin list whether somebody will object to making 32-bit Cygwin Emacs > a second-class citizen. We have not yet seen how well (or not) it works in practise, so I would not make that call today. Besides, there really is no way of knowing ahead of time what users actually do and I would not like to take that option away when just a small subset of users would run into trouble. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables