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.devel Subject: Re: [External] : emacs-28 windows binaries available from alpha Date: Sat, 05 Feb 2022 12:10:34 +0200 Message-ID: <83o83l1v51.fsf@gnu.org> References: <834k5d3hbv.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3497"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, drew.adams@oracle.com, emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 05 11:11:52 2022 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 1nGI2p-0000ha-6d for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Feb 2022 11:11:51 +0100 Original-Received: from localhost ([::1]:48130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nGI2n-00055S-J1 for ged-emacs-devel@m.gmane-mx.org; Sat, 05 Feb 2022 05:11:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGI1w-0004PI-64 for emacs-devel@gnu.org; Sat, 05 Feb 2022 05:10:56 -0500 Original-Received: from [2001:470:142:3::e] (port=60756 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nGI1u-0000ov-Sp; Sat, 05 Feb 2022 05:10:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=6ynLsG5deZNkUbHBCwWnWY9EjDQbtaGVRLn3lyGuvL8=; b=XUFo0waV/kEI c00Io4taLBbWPmGk1InAtt0YRCqdIs41kPz8jEYFEhWzaSC7IbxebCExGc7lHBZTIt1eD8DYHQfJq ZEt0JqmRmNRrzwSwuiDgXZYsn0uSJsLxC+nvFHko8DrWt0/H+/zc9Cb7t5pG/mkOD7tziH+kc71Pm t3z2VYfa8b3xJzOsyQC6TV6L/DA5V5zMcWdNHuujJdI7PQEOtxRZZIRHCWKtxzH5n+HbiS0Lghi/C dBZdtzA26iF/I2yjfb/QKc/+s2mNfj1JuRM0KdE6ec3qtzIzEX/Bc0gMB5tH7sZNba3YTP31DhJ4k smBOVYw2EgBfPV/6k4lLRA==; Original-Received: from [87.69.77.57] (port=1412 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 1nGI1u-0000hc-De; Sat, 05 Feb 2022 05:10:54 -0500 In-Reply-To: <834k5d3hbv.fsf@gnu.org> (message from Eli Zaretskii on Sat, 05 Feb 2022 09:25:56 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:285896 Archived-At: > Date: Sat, 05 Feb 2022 09:25:56 +0200 > From: Eli Zaretskii > Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org > > > Debugger entered--Lisp error: (error "Cannot find libgccjit library") > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > error("Cannot find libgccjit library") > > comp-ensure-native-compiler() > > comp--native-compile((lambda (arg0 &optional arg1 arg2 arg3) (let ((f #'read-buffer)) (funcall f arg0 arg1 arg2 arg3))) nil "d:/usr/drew/.emacs.d/eln-cache/28.0.91-bfc49136/su...") > > comp-trampoline-compile(read-buffer) > > comp-subr-trampoline-install(read-buffer) > > defalias(read-buffer #f(compiled-function (prompt &optional default require-match predicate) #)) > > load-file("~/drews-lisp-20/strings.elc") > > funcall-interactively(load-file "~/drews-lisp-20/strings.elc") > > command-execute(load-file record) > > execute-extended-command(nil "load-file" "load-f") > > funcall-interactively(execute-extended-command nil "load-file" "load-f") > > command-execute(execute-extended-command) > > Andrea, is this expected on a machine that lacks libgccjit? Under > what conditions would loading a .elc file trigger native-compilation > of a trampoline? > > If this is expected, I'd prefer that we detected the unavailability of > libgccjit earlier, and avoided the attempt to compile a trampoline in > the first place. Can this be done safely enough to make the change on > the release branch? Andrea, how about the following patch (which assumes comp-enable-subr-trampolines enables and disables only generation of new trampolines, but doesn't affect the use of existing trampolines)? Is this safe for the release branch, in your opinion? diff --git a/src/comp.c b/src/comp.c index 188dc6e..ba65837 100644 --- a/src/comp.c +++ b/src/comp.c @@ -434,6 +434,13 @@ load_gccjit_if_necessary (bool mandatory) gccjit_initialized = init_gccjit_functions (); status = gccjit_initialized ? Qt : Qnil; Vlibrary_cache = Fcons (Fcons (Qgccjit, status), Vlibrary_cache); + /* Disable deferred async compilation and trampoline synthesis + in this session, since libgccjit is not available. */ + if (!gccjit_initialized) + { + native_comp_deferred_compilation = false; + comp_enable_subr_trampolines = false; + } } if (mandatory && !gccjit_initialized)