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: Building a release tarball generates trampoline files in eln-cache Date: Thu, 04 Nov 2021 13:12:29 +0200 Message-ID: <83bl30fa3m.fsf@gnu.org> References: <8335pay5j0.fsf@gnu.org> <83pmsew854.fsf@gnu.org> <44da1bfa-9e13-07e9-10fe-27018f7d1369@cornell.edu> <83h7dqw0ga.fsf@gnu.org> <83h7dkm8n4.fsf@gnu.org> <831r4lid0n.fsf@gnu.org> <83zgr9gvvp.fsf@gnu.org> <83y26tgupl.fsf@gnu.org> <83bl3ogpob.fsf@gnu.org> <83r1c6v36p.fsf@gnu.org> <837ddqjt16.fsf@gnu.org> <83wnlqibkx.fsf@gnu.org> 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="34278"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: akrl@sdf.org, Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 04 12:15:50 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 1miaij-0008hN-BE for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Nov 2021 12:15:49 +0100 Original-Received: from localhost ([::1]:44100 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1miaih-0007Gt-Sb for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Nov 2021 07:15:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1miafW-0004Sz-CS for emacs-devel@gnu.org; Thu, 04 Nov 2021 07:12:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1miafV-0004lt-LG; Thu, 04 Nov 2021 07:12:30 -0400 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=o9x+iuTx6jircdXcAGRv48rYAMqve4cR1f8f0jaQkV4=; b=N8pat53n6sq2+Ap8t67F HrItIZ0iogl4uhtkeL28TsDogFTQIvsWBMSUV0nKgQS5QMhmOvYgAVUBX4B3NQVjcWqXga4S8FuSX bxMheCxy882m6MVWua/kpbcTxkeouPHd+DCY7dYWONoRNS2+zzMong5x+8MDjRS64yyGlKzhgoJ95 M+AU0O0iwEGK58tlCLg9g5BbdoEOUk30dW6Z0fDHKkzsKSqRXQYcOMBhAtoMHgjRcK41QrvU22tGt xAx7IPSiH9cEsEf45APzhAgVoyDBFneMQ6pK9fQa7GSEc202mAdFP0GkB5jRcawjDqxcqlTsXzVcK ypbTZDkeg58TyA==; Original-Received: from [87.69.77.57] (port=4975 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 1miafV-0001tJ-6O; Thu, 04 Nov 2021 07:12:29 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 02 Nov 2021 16:26:22 -0400) 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:278673 Archived-At: > From: Stefan Monnier > Cc: Andrea Corallo , emacs-devel@gnu.org > Date: Tue, 02 Nov 2021 16:26:22 -0400 > > Eli Zaretskii [2021-11-02 21:47:42] wrote: > >> From: Andrea Corallo > >> Cc: emacs-devel@gnu.org > >> Date: Tue, 02 Nov 2021 19:22:56 +0000 > >> > This shows errors in the *Compile Log* buffer(??) > >> > > >> > lisp/emacs-lisp/seq.elc: Error: Symbol’s function definition is void: gv-setter > >> > lisp/term/xterm.elc: Error: Symbol’s function definition is void: t > >> > > >> > If I delete seq.elc, the problem goes away. > >> > > >> > How do I investigate this? > >> > >> I guess a start is to run in gdb to see where the function definition of > >> gv-setter was last time changed (if ever). > >> > >> I guess `gv-setter' was compiled and dumped, therefore its definition > >> it's expected to be revived by 'load_comp_unit' called from > >> pdumper.c:5355 while Emacs is starting-up. > > > > Thanks, will try. > > > > Any idea why the errors show in *Compile Log* buffer? Where did that > > buffer come from? > > I'd guess that it's when `cl-generic.el` calls `byte-compile` (both > seq.el and xterm.el use `cl-defmethod`). > `cl-generic.el` is also one of the rare users of `gv-setter`. > OTOH, `gv-setter` normally doesn't appear within the code that > `cl-generic.el` passes to `byte-compile`, instead `gv-setter` is called > directly by `cl-generic.el`, so my guess might be off. Maybe, maybe not. The crucial detail here is that I invoke "emacs -nw" (are you using "-nw" in your attempts to reproduce?). What happens then is that we load the terminal-specific support file, in this case xterm.elc, during startup. And since xterm.el is not preloaded, it is not natively-compiled by the build process. So once we load it, Emacs tries to native-compile it, and all of its prerequisites, and that's where those errors and that compile log buffer come from, I guess. I tried to mark xterm.el and seq.el as not for native-compile, but that didn't help. However, if I manually compile gv.el natively into a *.eln file, the problem goes away. So why would Emacs want to native-compile gv.el in this case, and why trying that causes this problem? Maybe we should add gv.el to the list of files that are natively-compiled as part of the build? Interestingly, if gv-XXX.eln is available, Emacs still loads bytecomp at startup, but I don't see any evidence that it compiles xterm.el natively: no subprocesses and no xterm-XXX.eln files are created. Why does it load bytecomp, and what prevents it from natively compiling xterm.el in this case?