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: MSYS2 PATH problems with native compilation (was: msys2 build path problems + copy-paste english results in chinese characters) Date: Mon, 06 Dec 2021 16:32:33 +0200 Message-ID: <83lf0x248u.fsf@gnu.org> References: <83a6hks26v.fsf@gnu.org> <83pmqgqi6e.fsf@gnu.org> <87czmghqui.fsf@telefonica.net> <834k7rqxru.fsf@gnu.org> <87a6hebma1.fsf_-_@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13949"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 06 15:34:54 2021 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 1muF4w-0003R5-4k for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 15:34:54 +0100 Original-Received: from localhost ([::1]:46476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muF4v-0007fB-6h for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 09:34:53 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muF2h-0002dB-J3 for emacs-devel@gnu.org; Mon, 06 Dec 2021 09:32:35 -0500 Original-Received: from [2001:470:142:3::e] (port=54720 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 1muF2g-000482-V0; Mon, 06 Dec 2021 09:32:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=4im6TjNYF5Q3Vr+wxB0h40RFKif+9c69sLdobQOiX8M=; b=VCdO2mCQoRFcImS+ll5b Du/9J9/a+vh03+k/rg2OKZVE4YhrzNstCZOtwLP4RFtL2jRHfdTFosxQTea0qGBfWgCjHcHo+9HbT lS1TLi+GA9cm2sGs+Kzot7dqf+5vWNykkLJxy2A3BoRRUkQgjWGGaYB7sIAHUhvVsUg4X5cwxetLY sB6iX9Z6bs9GDz81wGVe+iZyL5CEWfk+vDrIjYvtF3TzKH7DKq+QVAKvb645YZQP7KE9ha4i9PsUL E5jOLr+zGZ6TkntyDcft/epY7ZfiFSmpapttRU4I+tDl7elU5kuiYcdWOiYww4+fIBM9xy3KYyrhg QcqvHJ+kPpyQGA==; Original-Received: from [87.69.77.57] (port=3887 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 1muF2g-0002uo-Ou; Mon, 06 Dec 2021 09:32:35 -0500 In-Reply-To: <87a6hebma1.fsf_-_@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Mon, 06 Dec 2021 01:38:14 +0100) 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:281120 Archived-At: > From: Óscar Fuentes > Date: Mon, 06 Dec 2021 01:38:14 +0100 > > I just checked in the recipe for building Emacs 28.0.90 on MinGW-w64 > (MSYS2) with native compilation enabled and found a serious problem. > > The Emacs MinGW-w64/MSYS2 package now depends on libgccjit package, > which means that libgccjit will be present when Emacs is installed. What do you mean by "depends on libgccjit"? Are you linking Emacs statically against the libgccjit DLL (via the import library)? If not, Emacs on Windows loads libgccjit dynamically, when it is first requested, and it doesn't need that library to start. So theoretically, MinGW64 users could decide not to install libgccjit, or have it unavailable to Emacs, and they will still be able to run Emacs, just not to natively-compile *.el files that you didn't compile ahead of time and provided in the binary distribution. > But if Emacs runs without its bin/ directory in PATH, libgccjit is > not functional (an error about missing as.exe is shown.) Only if you try to natively-compile *.el files (or Emacs tries doing that in the background). And, as you point out, not only libgccjit is needed if you do want to compile, the assembler and the linker are also needed. So the PATH problem is not only about libgccjit. > Creating a desktop icon for runemacs.exe and starting Emacs from there > is common. Also for MSYS2 users is common to work with multiple > architectures (mingw, clang, ucrt with their 32/64 bits variants) > simultaneously, and putting the binaries of one of those architectures > in global PATH is problematic. > > Hence it would be very convenient to use libgccjit without touching PATH. How is libgccjit different from any other DLL that Emacs loads dynamically, like libpng, for example? How do your users, who work with multiple architectures, cope with that wrt other DLLs that Emacs uses? > I ask again: would it be ok to add emacs.exe directory to PATH from > runemacs.exe or emacs.exe itself? > > Set PATH for the emacs instances used for generating the .eln files? "OK" from what POV? The MSYS2 project makes its own rules for configuring binary distributions, and those decisions are not necessarily aligned with the upstream project. Why do you ask here whether something you'd like to do in your distribution is OK or not? If you want to know my opinions, you already heard them. (And I still don't think I understand the underlying problem, even after your additional explanations, see above.) > Other solution? If you cannot put a DLL on PATH, the usual solution is to have it in the same directory as the .exe which needs it. Would that be a satisfactory solution for your problems?