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 Date: Tue, 07 Dec 2021 15:20:09 +0200 Message-ID: <83mtlczh4m.fsf@gnu.org> 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> <875ys1bb9f.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18986"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes , Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 07 14:22:24 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 1muaQG-0004Ri-F0 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Dec 2021 14:22:20 +0100 Original-Received: from localhost ([::1]:43618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1muaQE-0007ME-Hl for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Dec 2021 08:22:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52454) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1muaOD-0006SV-0d for emacs-devel@gnu.org; Tue, 07 Dec 2021 08:20:13 -0500 Original-Received: from [2001:470:142:3::e] (port=39530 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 1muaOC-0005AO-8O; Tue, 07 Dec 2021 08:20:12 -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=7Qo6Z+Ooh3BT1vkGdlD1fZqEMLEod6DDacT4AprWq3Y=; b=cLu2ux1IdgP/GDUc2FB7 cKiCb/KvmyHv6CDUEvHMojuTUViYPrV0S0xSIThv/fVc4TDncXk4D8fNfUtYkmGv52zloQwXbik97 kkUB+Hz4ceZFwZMenRPYYwDFx+2+KNIwxL8gf2GBxmo9crRsMPRMcfOQeJVNodNLF5K/0jmzagq1C xOEVh+u6LsvdKeKbZlUnzk+B9vKXDEr3q80YbuByVJkj3coESuVHUvjqfOCDFFqACUA17uiwJJv2w TM/SGVW585ywAoW/BTwmKIUEWfsSITYsAZYf3e5Mk4PJg8s2NVRbbqgQPPZfywwd+FNSXlxf4esFf hUDnTRyVQ995Zw==; Original-Received: from [87.69.77.57] (port=4613 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 1muaO9-0004b8-1A; Tue, 07 Dec 2021 08:20:12 -0500 In-Reply-To: <875ys1bb9f.fsf@telefonica.net> (message from =?iso-8859-1?Q?=D3scar?= Fuentes on Mon, 06 Dec 2021 23:48:28 +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:281239 Archived-At: > From: Óscar Fuentes > Date: Mon, 06 Dec 2021 23:48:28 +0100 > > 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. So you were talking about libgccjit, but actually meant the assembler and the linker programs, not the libgccjit DLL? That was hard to guess. If the problem is with the Binutils that are invoked as part of the compilation, then I think I understand the problem even less. For starters, AFAIK we don't search for those in the Emacs code, it's libgccjit that invokes them in its own code, according to the rules of a "usual" GCC installation. Andrea, am I mistaken? I don't see any use of exec-path in the nativecomp code that would look for the assembler and the linker, am I missing something? If I'm right, then nothing you do with PATH in Emacs can guarantee that native-compilation will find Binutils, because that depends on how GCC and Binutils were installed and how they search for the programs they need. IOW, I believe that libgccjit relies on a functional GCC installation, including the subprograms under libexec and (perhaps) some system header files? I don't even know what it expects, because AFAIU its prerequisite is a working GCC and Binutils installation. But if PATH does make a differenceand can solve your problem, by some indirect way, then did you try to put the assembler and the linker in the libexec/emacs/ tree, where we keep auxiliary programs Emacs invokes? Emacs searches there by default. > >> 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. You want Emacs to change the user's PATH by default? That'd be unthinkable, IMO. Programs have no business messing with user's PATH, since that could easily mess up user's system. E.g., suppose the user already has a development environment installed and on PATH: then you are silently causing "M-x compile" to use different Binutils programs than what the user intended. > 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. I don't know what kind of GNU/Linux installations you have in mind, but I don't know about any reliable installation technique that causes all the installed tools to seamlessly work together, except by either modifying PATH or installing all the tools in the same common tree. Anything else is much more complex and fragile. Having several incompatible development environments on the same machine active simultaneously is IME a very rare use case, but if your users do that frequently, and you don't have some system of batch files/scripts to easily and reliably switch between the environments, then your users are in for a lot of trouble.