From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Loading tramp for dump goes into infinite regress Date: Sun, 24 Jul 2022 08:05:30 -0400 Message-ID: References: <8735erhrlg.fsf@gmx.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f9758105e48be290" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29970"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 24 14:07:12 2022 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 1oFaO7-0007e6-Im for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 14:07:11 +0200 Original-Received: from localhost ([::1]:41658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFaO3-0005Ug-Im for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 08:07:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53970) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFaMk-0004QJ-Lt for emacs-devel@gnu.org; Sun, 24 Jul 2022 08:05:46 -0400 Original-Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]:36470) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFaMi-0005hH-QN for emacs-devel@gnu.org; Sun, 24 Jul 2022 08:05:46 -0400 Original-Received: by mail-oi1-x22e.google.com with SMTP id u76so10430159oie.3 for ; Sun, 24 Jul 2022 05:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rU1wd1KO/JolnfDv6118uBjbu+iSS0BLBEmY3HUPEvE=; b=AzsHFHhD/zCoB7e7hrgO5+9VMk8JSFhPhRlXym8ng0UctNZgyETsB230sxtPOwh9R3 z8Ts/afXw2Cv6MlSGfCpZUouXzJCS97N4Rlk7QluCcwGrud3vnPa2c1mG42wV1PVGYS2 +kAlWwKgcnxAyJDn60Bq7RhGq31tlxumkg52kSX2AnrTV0yYteLK/9ItyVozdJOg6YVA xl54Aycc3gbkpvM90ong0rP/sUeDyYBJaoi/Ka+Ud7nQXGzMU/K+i02eKMw+voogUWw6 RXSLjwrnqWII4KuW7pCEfge7vzfLoo3996kGSzta8nrwPht66g8+Z1oTxzfXNJBrneGm /wMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rU1wd1KO/JolnfDv6118uBjbu+iSS0BLBEmY3HUPEvE=; b=V48Ihe94VYhNN29ybYDDpKtioJ6/s28R1aZORuMVGNpN4ujK5B1Lq5IHFneEjzIlzE XvtNVckAgrVOU9ixdmUTjo42lB4JNG20OwxYEnf8CBHwR/yulNi6DX6bd7/PO9tLBI8G 17205DhIJfzmGWLzdnAdAEMZf7s+ye/E7MBiidTfaGluMvNs/uk9b3PMBTbHKg4E18cJ 9XoHWm1W9fdI7EglYdCmnUNZehhAk5dkZbO5EsLVSoC2dJQYtCw3rJoH1WVCs79HyqnK LWbq7PiGrR/2rCMcFXviAEiQsOObzskvwNfi6Wyuq+q14gbsCGdQT9xUNy8/DDdNoEM0 Gdqg== X-Gm-Message-State: AJIora8abXJAyly584pj3SUZTofcUwTBSr5OitwfPe7rJMmjn/q8e0+6 wDsc7WZhs014PNywee4Q/24d8LRQw7GD7S3U4LM= X-Google-Smtp-Source: AGRyM1sq7ZSvWoNPt2EjwQ0Kny09KqbICESYAKtZjZLTNYjqtcO9XaLH4bUOUnuuuzS3sDubL3YyMbP9DcSqf6cX8VY= X-Received: by 2002:a05:6808:e89:b0:33a:315a:eb90 with SMTP id k9-20020a0568080e8900b0033a315aeb90mr3416467oil.162.1658664343137; Sun, 24 Jul 2022 05:05:43 -0700 (PDT) In-Reply-To: <8735erhrlg.fsf@gmx.de> Received-SPF: pass client-ip=2607:f8b0:4864:20::22e; envelope-from=owinebar@gmail.com; helo=mail-oi1-x22e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:292579 Archived-At: --000000000000f9758105e48be290 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 24, 2022, 3:55 AM Michael Albinus wrote: > Lynn Winebarger writes: > > Hi Lynn, > > > And I don't even know where to start describing the issue. > > I don't even understand what you're trying. Could you pls give the > commands you're calling, that I have a chance to reproduce? > Good point. I'm trying to dump a "fully-loaded" emacs 28.1 that includes several hundred packages from the various elpas. I've modified those packages so they reside in site-lisp, use cl-lib instead of cl, and use an explicit data directory instead of loading files relative to the location of an installed .el file. I verified these all "work" by having about 1000 require statements in my .emacs file to explicitly require them. I then took the load history and separated the files into ones from the lisp directory and ones from site-lisp. I created a site-load.el and site-lisp-load.el (loaded at the end of site-load.el) to explicitly load the files in something resembling dependency order, then running make in the emacs build directory to create the build. I've also compiled every ELISP source file using batch-byte+native-compile. That was really painful since, as far as I know, the files can't be native compiled in parallel in arbitrary order because of potential race conditions, and I haven't made a Makefile for the .ELN files with the correct dependencies to native compile them in dependency order using make to build them in parallel. Now I'm working through the site-load.el file to dump all the required core emacs ELISP files first (in addition to the ones in loadup) to get the ordering right. Tramp is somewhere in the 300s in the list, maybe halfway-through the list of core emacs files. I don't really expect anyone to be able to solve this for me. I'm just looking for some pointers on how I can figure out what is going on short of stepping through the dumping process with gdb. At this point, I'm just trying to figure out why I can native compile tramp, but the load statement during the load preparing for dumping goes into infinite regress. The "require 'tramp-loaddefs" statement was an obvious problem, so I took the steps I described in my first email to resolve them. I just don't understand what's going on when I end the tramp.el file with "(eval-and-compile (provide 'tramp))" and comment out the final statements that run the initialization hook. When I try to native compile that version of tramp.el, it still seems to attempt to run the initialization hook when the provide statement is evaluated during the compile. I have no idea why that is happening. I would suspect something along the lines of "with-eval-on-load 'tramp", but I can't find it. Any ideas would be appreciated. Lynn --000000000000f9758105e48be290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 24, 2022, 3:55 AM Michael Albinus <michael.albinus@gmx.de> wrote:
Lynn Winebarger <owinebar@gmail.com= > writes:

Hi Lynn,

> And I don't even know where to start describing the issue.

I don't even understand what you're trying. Could you pls give the<= br> commands you're calling, that I have a chance to reproduce?

Good point.= =C2=A0 I'm trying to dump a "fully-loaded" emacs 28.1 that in= cludes several hundred packages from the various elpas.=C2=A0 I've modi= fied those packages so they reside in site-lisp, use cl-lib instead of cl, = and use an explicit data directory instead of loading files relative to the= location of an installed .el file.=C2=A0=C2=A0
I ve= rified these all "work" by having about 1000 require statements i= n my .emacs file to explicitly require them.=C2=A0 I then took the load his= tory and separated the files into ones from the lisp directory and ones fro= m site-lisp.=C2=A0 I created a site-load.el and site-lisp-load.el (loaded a= t the end of site-load.el) to explicitly load the files in something resemb= ling dependency order, then running make in the emacs build directory to cr= eate the build.
I've also compiled every ELISP s= ource file using batch-byte+native-compile.=C2=A0 That was really painful s= ince, as far as I know, the files can't be native compiled in parallel = in arbitrary order because of potential race conditions, and I haven't = made a Makefile for the .ELN files with the correct dependencies to native = compile them in dependency order using make to build them in parallel.

Now I'm working through = the site-load.el file to dump all the required core emacs ELISP files first= (in addition to the ones in loadup) to get the ordering right.=C2=A0 Tramp= is somewhere in the 300s in the list, maybe halfway-through the list of co= re emacs files.

I don= 9;t really expect anyone to be able to solve this for me.=C2=A0 I'm jus= t looking for some pointers on how I can figure out what is going on short = of stepping through the dumping process with gdb.=C2=A0=C2=A0

At this point, I'm just trying to= figure out why I can native compile tramp, but the load statement during t= he load preparing for dumping goes into infinite regress.=C2=A0 The "r= equire 'tramp-loaddefs" statement was an obvious problem, so I too= k the steps I described in my first email to resolve them.=C2=A0 I just don= 't understand what's going on when I end the tramp.el file with &qu= ot;(eval-and-compile (provide 'tramp))" and comment out the final = statements that run the initialization hook.=C2=A0 When I try to native com= pile that version of tramp.el, it still seems to attempt to run the initial= ization hook when the provide statement is evaluated during the compile.=C2= =A0 I have no idea why that is happening.=C2=A0 I would suspect something a= long the lines of "with-eval-on-load 'tramp", but I can't= find it.

Any ideas woul= d be appreciated.=C2=A0

= Lynn



--000000000000f9758105e48be290--