From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] [WIP] Port feature/native-comp to Windows. Date: Sun, 10 May 2020 11:54:05 -0700 Message-ID: References: <5eb5b953.1c69fb81.a67ce.a764@mx.google.com> <83lfm1hc91.fsf@gnu.org> <83wo5lds87.fsf@gnu.org> <83imh3d840.fsf@gnu.org> <83eerrd4mb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="74641"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: nicolasbertolo@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 10 20:54:59 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 1jXr6I-000JJ5-Iw for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 20:54:58 +0200 Original-Received: from localhost ([::1]:38726 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXr6H-0006CF-En for ged-emacs-devel@m.gmane-mx.org; Sun, 10 May 2020 14:54:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXr5W-0005gU-GR for emacs-devel@gnu.org; Sun, 10 May 2020 14:54:10 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:61539) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jXr5U-0008OB-NW; Sun, 10 May 2020 14:54:10 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04AIs5VP022272 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 10 May 2020 18:54:06 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04AIs5nj003158; Sun, 10 May 2020 11:54:05 -0700 In-Reply-To: <83eerrd4mb.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 10 May 2020 21:30:52 +0300") Received-SPF: pass client-ip=205.166.94.20; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/10 11:24:46 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:249697 Archived-At: Eli Zaretskii writes: >> 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? Yes. > Does the embedded driver know where GCC is installed on the system > where Emacs runs, and where to find the support libraries? The embedde driver is just some code some code in libgccjit that act as the original gcc executable so has not need to be located. For the support libraries is the linker that does that conventionally. You can even log the ld invocation done by the embedded drive is nothing magical. Finally the linker is just the system one. > 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? That is my understanding. > 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. Me too I do not understand why ld is not doing the expected job, I guess I've to re-read the thread. Andrea -- akrl@sdf.org