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: Sun, 10 May 2020 21:30:52 +0300 Message-ID: <83eerrd4mb.fsf@gnu.org> References: <5eb5b953.1c69fb81.a67ce.a764@mx.google.com> <83lfm1hc91.fsf@gnu.org> <83wo5lds87.fsf@gnu.org> <83imh3d840.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="130685"; mail-complaints-to="usenet@ciao.gmane.io" Cc: nicolasbertolo@gmail.com, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 20:36:44 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 1jXqoe-000XuM-MV for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 20:36:44 +0200 Original-Received: from localhost ([::1]:57408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXqod-0002tX-BG for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 14:36:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44964) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXqjA-0007oq-OT for emacs-devel@gnu.org; Sun, 10 May 2020 14:31:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47677) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXqj7-0006GA-Bu; Sun, 10 May 2020 14:31:01 -0400 Original-Received: from [176.228.60.248] (port=1358 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXqj5-00060B-7v; Sun, 10 May 2020 14:31:00 -0400 In-Reply-To: (message from Andrea Corallo on Sun, 10 May 2020 11:14:11 -0700) 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:249695 Archived-At: > From: Andrea Corallo > Cc: nicolasbertolo@gmail.com, emacs-devel@gnu.org > Date: Sun, 10 May 2020 11:14:11 -0700 > > libgccjit when has produced the .s file has to invoke the "driver". > This is in GCC jargon the usual gcc executable that his the program that > is responsible for calling cc1 as and ld. > > libgccjit can invoke the driver in two ways, one is using the embedded > one (default) or it can search for an external driver (the system gcc > executable). AFAIU when the driver takes over the conventional logic to > identify support library is used by the linker. And on GNU/Linux we use the default, i.e. the embedded driver? Does the embedded driver know where GCC is installed on the system where Emacs runs, and where to find the support libraries? If not, why not? After all, I presume libgccjit is just one component of the GCC installation, so it shares the environment and the search lists with the locally installed gcc driver, no? If for Windows we decide to use the external driver, i.e. the gcc.exe installed on the end-user's system, does it solve all the problems with finding the auxiliary programs and support libraries? If so, I think this way is better, at least on MS-Windows (if not on all systems). > Using gcc_jit_context_add_driver_option you can pass parameters to the > driver that will forward them to the linker. Sure, but it sounds like knowing what those parameters are is not a simple job. Although I still don't seem to understand why, silly me. Thanks.