From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: MSYS2 PATH problems with native compilation Date: Mon, 06 Dec 2021 23:48:28 +0100 Message-ID: <875ys1bb9f.fsf@telefonica.net> References: <83a6hks26v.fsf@gnu.org> <83pmqgqi6e.fsf@gnu.org> <87czmghqui.fsf@telefonica.net> <834k7rqxru.fsf@gnu.org> <87a6hebma1.fsf_-_@telefonica.net> <83lf0x248u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31360"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:zYxQ2EclqrUOEcbTcCrT0PEU8Zk= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 06 23:49:53 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 1muMnx-0007uG-3c for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 23:49:53 +0100 Original-Received: from localhost ([::1]:46714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muMnw-0000Vo-3Z for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Dec 2021 17:49:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38776) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muMmp-00066T-W5 for emacs-devel@gnu.org; Mon, 06 Dec 2021 17:48:45 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:57522) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muMmn-0007MC-Pw for emacs-devel@gnu.org; Mon, 06 Dec 2021 17:48:43 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1muMml-0006Gh-LD for emacs-devel@gnu.org; Mon, 06 Dec 2021 23:48:39 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:281185 Archived-At: Eli Zaretskii writes: >> 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"? It is a package dependency, meaning that if the user installs the emacs package, it is guaranteed that libgccjit will be installed too. >> 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? DLLs that Emacs load dynamically are not a problem, they all work fine (including libgccjit dll). The problem is for executables invoked by Emacs, because Emacs searchs for them using exec-path (which itself depends on the initial value of PATH.) This is different to what CreateProcess does which, as you very well know, always searches the executable on the same directory as the calling process' executable, first thing. This means that Emacs deviates from the stablished rule on Windows, and that deviation causes a degraded experience. To recap: libgccjit dll is fine, but as.exe/ld.exe/etcetera are not found despite being installed right there along emacs.exe. >> 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? >From your POV, of course. I'm talking about making changes to Emacs. > 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? We could locally patch Emacs, of course, but "fixing" the upstream project is preferable. > 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? This is not about DLLs, as stated above. The general problem is that Emacs is installed along all the tools it needs, but they are invisible to Emacs unless you explicitly say "they are right there where you are!". That's not the experience we get on GNU/Linux and other systems, where Emacs has no problem finding any executable as long as it is installed where the package manager puts it by default.