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#50666: 28.0.50; Fix native compilation on Cygwin Date: Thu, 23 Sep 2021 10:42:33 +0300 Message-ID: <83o88jvity.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5171"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org To: Ken Brown , Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 23 09:43:10 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 1mTJNt-0001Br-Ta for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Sep 2021 09:43:09 +0200 Original-Received: from localhost ([::1]:46142 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTJNs-0002A2-79 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Sep 2021 03:43:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mTJNm-00029e-9H for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:43:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41037) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mTJNm-0004TS-2J for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mTJNl-000149-Tm for bug-gnu-emacs@gnu.org; Thu, 23 Sep 2021 03:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Sep 2021 07:43:01 +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 Original-Received: via spool by 50666-submit@debbugs.gnu.org id=B50666.16323829674076 (code B ref 50666); Thu, 23 Sep 2021 07:43:01 +0000 Original-Received: (at 50666) by debbugs.gnu.org; 23 Sep 2021 07:42:47 +0000 Original-Received: from localhost ([127.0.0.1]:52583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTJNX-00013e-7O for submit@debbugs.gnu.org; Thu, 23 Sep 2021 03:42:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTJNT-00013N-Th for 50666@debbugs.gnu.org; Thu, 23 Sep 2021 03:42:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36090) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mTJNM-00046Z-M0; Thu, 23 Sep 2021 03:42:36 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2312 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 1mTJNM-0004Gi-8D; Thu, 23 Sep 2021 03:42:36 -0400 In-Reply-To: <4ae8067f-55b2-d243-66f3-f76493095a39@cornell.edu> (message from Ken Brown on Wed, 22 Sep 2021 17:35:28 -0400) 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:215168 Archived-At: > Cc: Stromeko@nexgo.de, 50666@debbugs.gnu.org > From: Ken Brown > Date: Wed, 22 Sep 2021 17:35:28 -0400 > > We've made a good start on the Cygwin side, but I have a question about how to > integrate it into Emacs. I added Andrea to this discussion, as he knows more than anyone else about the Emacs side of this stuff. > Let's say we have a script that I'll call "rebase" for the purpose of this > discussion, which rebases all the eln files in ~/.emacs.d/eln-cache. The user > would then start Emacs via a script that first calls rebase and then starts > Emacs. Is it really necessary to rebase the *.eln files before each startup? Isn't it enough to rebase each of the .eln files just once, when it is produced? If indeed this is needed every time, can you explain why? > Within Emacs, I would then want to do something like > > (if (eq system-type 'cygwin) > (call-process "rebase" nil > '(:file "") > nil "" ...)) > > after every compilation but before the compiled file is loaded. > > I'm not familiar enough with native compilation to know where this should go. The non-preloaded *.eln files are all loaded by native-elisp-load, so I guess the rebase should be launched from there? The preloaded *.eln files are loaded in pdumper.c:dump_do_dump_relocation, but do we need to support non-rebased preloaded *.eln files? > Or maybe it has to be done in more than one place, depending on whether the > compilation is synchronous or not. > > Can you help? I hope the above helps. But I think we should understand better all the aspects of this issue, to make sure it will work correctly in the wild. The *.eln files bring quite a few new and unusual aspects and dependencies to Emacs, they are not just another kind of DLLs loaded dynamically. So I'd appreciate if you explained: . why is rebasing needed (I think I understand that part, but I'd prefer an explanation from the experts) . how will the 'rebase' utility determine to which address to remap each .eln file > P.S. The rebase script will fail to rebase eln files that are already loaded, > but that's harmless in the scenario above. When an updated .eln file is produced for .eln that is loaded into some running Emacs, Emacs on Windows renames the original .eln to avoid a similar problem. Can't you use the same technique, to avoid the need of rebasing on each start? Please note that users could place *.eln files in unusual locations (and customize native-comp-eln-load-path to reflect that), so finding _all_ of the relevant *.eln files from a shell script might not be easy. In fact, even without customizing the load-path, I don't think I understand how will that script you propose know where to find all the *.eln files. Thanks.