From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows. Date: Sat, 09 May 2020 18:48:40 +0300 Message-ID: <83wo5lds87.fsf@gnu.org> References: <5eb5b953.1c69fb81.a67ce.a764@mx.google.com> <83lfm1hc91.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="42687"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Nicolas =?utf-8?Q?B=C3=A9rtolo?= , Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 09 17:49:41 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 1jXRjQ-000Ayu-2V for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 17:49:40 +0200 Original-Received: from localhost ([::1]:39994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXRjO-0001F3-IA for ged-emacs-devel@m.gmane-mx.org; Sat, 09 May 2020 11:49:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXRik-0000gc-Ih for emacs-devel@gnu.org; Sat, 09 May 2020 11:48:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54145) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXRik-0001Fm-8Y; Sat, 09 May 2020 11:48:58 -0400 Original-Received: from [176.228.60.248] (port=3185 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXRib-0003TQ-A2; Sat, 09 May 2020 11:48:57 -0400 In-Reply-To: (message from Nicolas =?utf-8?Q?B=C3=A9rtolo?= on Sat, 9 May 2020 12:28:29 -0300) 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:249478 Archived-At: > From: Nicolas Bértolo > Date: Sat, 9 May 2020 12:28:29 -0300 > Cc: emacs-devel@gnu.org > > > Also, did you try compiling the modified code with the 32-bit MinGW64 > > compiler? > > I haven't tried to compile it with the 32-bit compiler. This could have issues with setjmp, I think. > There are many ways to call setjmp() in Windows. It depends on the architecture, > whether the Universal CRT is used, whether SEH is enabled, the compiler version, > etc. Yes, I know. But we need to support only the way we compile Emacs, right? > I tried copying the assembler and linker (as.exe and ld.exe) into the folder > where emacs.exe lives. It is necessary to add that folder to PATH, that is the > first issue I found. Why do you need this? The following command will show you the full absolute file name of the assembler being used by GCC: gcc -print-prog-name=as And similarly with ld.exe and any other program that GCC needs to invoke as party of the compilation. Can we use that instead of adding directories to PATH? In fact, I wonder how does the native-compilation branch solve this for GNU/Linux systems, if not like that? > If I remove the MSYS installation folder then it fails with these errors: > > libgccjit.so: error: error invoking gcc driver > > -or- > > ld: cannot find dllcrt2.o: No such file or directory > ld: cannot find crtbegin.o: No such file or directory > ld: cannot find -lmingw32 > ld: cannot find -lgcc_s > ld: cannot find -lgcc > ld: cannot find -lmoldname > ld: cannot find -lmingwex > ld: cannot find -lmsvcrt > ld: cannot find -lpthread > ld: cannot find -ladvapi32 > ld: cannot find -lshell32 > ld: cannot find -luser32 > ld: cannot find -lkernel32 > ld: cannot find -lmingw32 > ld: cannot find -lgcc_s > ld: cannot find -lgcc > ld: cannot find -lmoldname > ld: cannot find -lmingwex > ld: cannot find -lmsvcrt > ld: cannot find crtend.o: No such file or directory Sounds like something is broken in the MinGW libgccjit port? It seems not to pass the correct -L switch to the compiler, or something along those lines? Does libgccjit has the equivalent of the -v switch, which would show the complete commands used to compile? > You are right when you say that they are native Windows programs. They don't > need a "pseudo-unix" environment like I said previously. But they need some > support files from the MSYS installation. I haven't figured out which ones yet. Well, please try to figure that out, and let us know if we can help you in that task. Once we understand the issues, we could think about solving them. > >> Subject: [PATCH 4/6] Handle LISP_WORDS_ARE_POINTERS and > >> CHECK_LISP_OBJECT_TYPE. > > > Is this specific to MS-Windows? If so, what is the MS-Windows > > specific aspects of native compilation that require this? > > This is partially specific to Windows. I had trouble compiling it with the > `--enable-check-lisp-object-type` configure option, so I had to add support for > it. But --enable-check-lisp-object-type is not specific to Windows. Andrea, is this configuration option supported by the branch on Posix platforms? > One aspect that is specific to Windows is that sizeof(void*) != sizeof(long) > even if WIDE_EMACS_INT is not defined. The code assumed that sizeof(Lisp_Word) > == sizeof(long) if WIDE_EMACS_INT was not defined. I fixed this by adding many > types that represent the Lisp_* family and changing the code to use these > instead of long and long long. That's a general bug, and should be fixed on all platforms. WIDE_EMACS_INT is supported on Posix platforms as well; I guess no one has yet tried to make a 32-bit build of the branch --with-wide-int.