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.bugs Subject: bug#71801: emacs 29.4 windows binaries Date: Sat, 06 Jul 2024 19:20:09 +0300 Message-ID: <86sewm332e.fsf@gnu.org> References: <86tthe4ei5.fsf@gnu.org> <861q477l1w.fsf@gnu.org> <86y16f5a5k.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24866"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tclwarrior@gmail.com, corwin@bru.st, 71801@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 06 18:21:15 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sQ89z-0006GU-8N for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jul 2024 18:21:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQ89k-0005QY-It; Sat, 06 Jul 2024 12:21:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQ89i-0005QE-QC for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2024 12:20:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQ89i-0004Ef-Da for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2024 12:20:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sQ89l-0005XE-OB for bug-gnu-emacs@gnu.org; Sat, 06 Jul 2024 12:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jul 2024 16:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71801 X-GNU-PR-Package: emacs Original-Received: via spool by 71801-submit@debbugs.gnu.org id=B71801.172028282821224 (code B ref 71801); Sat, 06 Jul 2024 16:21:01 +0000 Original-Received: (at 71801) by debbugs.gnu.org; 6 Jul 2024 16:20:28 +0000 Original-Received: from localhost ([127.0.0.1]:46611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQ89D-0005WG-Er for submit@debbugs.gnu.org; Sat, 06 Jul 2024 12:20:28 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59572) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQ89A-0005W3-E3 for 71801@debbugs.gnu.org; Sat, 06 Jul 2024 12:20:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQ890-000441-EE; Sat, 06 Jul 2024 12:20:14 -0400 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=wSBlLRyr/4QfnOwLxecOKJv/adZbdJgV0WD60rkep6g=; b=ayjYaUhLpZHF tqtjJTDcAa0qL1I3M1LnU+5RulDB5dnQk3NZZ2MLcvevfoM1V0pSv6IKtgBMPD+XwaTIPC23pI07L mBya593tGoDzEgJfocuV47/j73tK2cYB/XxeASRbC/m4AOb2Px64py7g4BQ0vpx8HrEgCqSUjF5BV zPdh2kDPBk12T6mfFyT6IlvdDdFTqlopsB9wO9wAM1QMlStepWCYRQkhIjNjS32SiNtBkNuXYBWpa n8jI1K5mHCDzGv1AjiEhfzx99dMRV9eAcTFVFWEdsqTZU0xqgKi3Z2q5wPYbvrl444/c+JNvDVEMA hDdavHFj4LbMQJr3UiyzAQ==; In-Reply-To: (message from Drew Adams on Sat, 6 Jul 2024 15:33:49 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288509 Archived-At: > From: Drew Adams > CC: "corwin@bru.st" , > "tclwarrior@gmail.com" > , > "71801@debbugs.gnu.org" <71801@debbugs.gnu.org> > Date: Sat, 6 Jul 2024 15:33:49 +0000 > > > > > You need to install GNU Binutils, which is where as.exe, the GNU > > > > assembler, comes from. > > > > > > Why? > > > > It's needed for JIT native compilation of Lisp. > > Until now, there has been no requirement > to have anything that's needed to support > native compilation. Until now, Emacs just > ignored native compilation if the local > "infrastructure" to support it was missing. > > That approach was good. As Corwin explained already, he made a packaging mistake, whereby the "infrastructure" in support of native compilation was half-present and half-absent. > > > > > I haven't noticed other problems yet (with -Q), but > > > > > is the continual emission of that warning expected? > > > > > > > > Yes. > > > > > > Why is that a good thing to do? > > > > It isn't supposed to happen in a working Emacs installation. > > I see. You mean the warning itself, or > the need for a user to have whatever's > needed to support native compilation? Neither. What isn't supposed to happen is that you have GCC and libgccjit, but not Binutils. You should either have all of them, or none, then the silent fallback on byte-compiled code will work. What happened in your case is that Emacs found libgccjit, so it decided the native compilation was supported, but libgccjit choked when it actually tried to compile Lisp to native code. > > Its absence is like the absence of dired.el/dired.elc: it should not > > happen. So by default Emacs warns about it every time it wants to > > natively compile a file. > > So is it only a problem with the Emacs build, > or is Emacs considering that the user's > context is inadequate and the user needs to > do something to remedy that? It depends on the user. If the user is the one who set up the development and run-time environment, then the user should fix it to be fully operable. If the user just installed a binary distro, he/she should take this up to whoever produced the distro. > > > > > Clicking that black, square icon pops up this > > > > > question as a menu: > > > > > > > > > > Suppress `comp' warnings? > > > > > _________________________ > > > > > > > > > > Yes, Ignore `Comp' Warnings Completely > > > > > No, Just Disable Showing Them > > > > > Quit And Do Nothing > > > > > > > > > > I have no idea what any of that means. > > > > > > > > It allows you to disable these warnings, so that they don't annoy you. > > > > > > Sure. But _what are_ `Comp' warnings? > > > > They are the warnings labeled 'comp', as in the warning you've shown. > > So just as meaningless as if the label were 'foobar' > or 'guess-what-this-means'. No, not just as meaningless. > > > How is someone to know whether they might want to (or need to) > > > ignore, disable, or do nothing? > > > > By reading the warnings, understanding what they say and mean, and > > deciding what to do with them. It's a user decision. > > So this is a user problem, not an Emacs build > problem? (That's what user warnings are for.) It is a problem with the Emacs installation. Who should fix it depends on how and by whom Emacs was built and installed. Emacs itself cannot know that. > If so, that's the problem with the warning: > it's not comprehensible to many (most?) users. > The "user decision" can't be based on any real > understanding of what's involved (in this case). Users who don't understand the warning will do what they always do: search the Internet or ask on known forums. > > Isn't it you that always requests to let the > > users the freedom of deciding how to > > deal with non-trivial situations? > > Not by not making clear to them what they can > or need to decide, giving them the info needed > to do that. Which we did here. > > That's what Emacs does there. > > I don't see it that way. I don't understand > the message, and it sounds like someone needs > to know something about Emacs builds, its > dependencies, and perhaps native compilation. That's okay. Some warnings will invariably left not understood by some of the users, especially if they (users) lack background knowledge about what happens in that case. The usual remedy is to ask. > > That's an unfair comparison. The warning in question did tell you > > what was the problem: a specific program was missing or could not be > > found. > > What's the meaning/consequence of that program > being missing? If you know that Emacs compiles Lisp to native code, you will understand the meaning of the assembler program being absent. If you don't, you won't, and will have to ask or look around for answers. > > > x86_64-w64-mingw32-gcc-11.3.0: fatal error: cannot > > > execute 'as': CreateProcess: No such file or directory > > > > > > Is that a problem? I'm warned about it, so I > > > guess maybe it is. Is it a problem that I'm > > > expected, and that I can, do something about? > > > If so, what needs to be done? > > > > What needs to be done is find out why GCC could not fine 'as', and fix > > that. > > The warning doesn't tell users that they need to > do that, and _how_ to do it. It can't. There are gazillion reasons for the problem, each one with a different solution. One can write a small paper mentioning and explaining them all. It's impractical to expect Emacs to do that in a warning. What Emacs does here is point out that a certain required program is missing. It should be good enough to understand the problem, like it is good enough when Emacs says some file is missing. Or take this message as an example: Autoloading failed to define function SUCH-AND-SUCH Users who don't know what autoloading is or does will be unable to understand it or know how to fix it. Like in this case. > > > And your response is that this is all OK > > > and expected? > > > > No. My response was quite more than that. > > I'd say that the warning isn't very helpful > to many/most users who would encounter it - > unless it's never supposed to be seen and it > results from a faulty Emacs build and is not > really a user problem. > > For most users to understand and act on the > problem, I think the info communicated would > need to be much better. You are entitled to your views, but I don't share them. And I don't agree with your estimation of how many users won't understand what the warning says. (I also don't understand why we are still arguing when Corwin already explained why the problem happened, and already uploaded a fixed distribution.)