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: Wed, 3 Aug 2022 05:58:17 -0400 Message-ID: References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000063b75705e5534622" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22775"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Michael Albinus , emacs-devel To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 03 12:12:18 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 1oJBMP-0005mK-Uk for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 12:12:18 +0200 Original-Received: from localhost ([::1]:40458 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJBMO-0003WU-9W for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 06:12:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJB97-0006eY-EE for emacs-devel@gnu.org; Wed, 03 Aug 2022 05:58:33 -0400 Original-Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]:44731) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJB95-00044p-Oa; Wed, 03 Aug 2022 05:58:33 -0400 Original-Received: by mail-pg1-x534.google.com with SMTP id bf13so14650147pgb.11; Wed, 03 Aug 2022 02:58:30 -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=TcTq468+hVM3Jm0V4WtyP52v1fsr7KKK/xTXQclgvbc=; b=hqmMkpvh+9CnKSKZ2Ljx/f37F7YkRX50kVFBJmKM4dtV0cEcEDvbYU3UuZOyP3rN/U yVWBAtI0PQ43w+5bMX181Dc1UlqLWyQYegeN4FAeYZ9Xtq28+DTM6O7Ytcz1PZUTcRxj wFb0aXDqezsyH9yWpe5MCzkn97fDVlI1c+XX1nNQxHalbA/DKFOvQgbIWUJ80Kv8+z2p XS4Qu8O3xDJRYE87DEEIXDhuJntzdF9JJTB10HurtPU7eHI99edouEW17NnGzHtn/RVI uMVx48+Et51rOhVtUO4dQx55ZAGQ01+CiH2AoGAjs1Z00VCD2dXjakZOXIVfEboHV8gC ohlQ== 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=TcTq468+hVM3Jm0V4WtyP52v1fsr7KKK/xTXQclgvbc=; b=ZZZyHqv+PYEeESANVwKgErFTMXMKdCOdkrBssw+MvXlKKBQGRF4yN6oLbjAehihY8b gghUhWcbahy0J9Nlrq45AYf/XaTQ0Bv6cRqxlIucc0mQAqtqZc42o8ki3mScC+VOzSO6 Et8d8G3EmcyaV5OPU0qbj35WKjVjj6OgYDOUGuMPGq5K9TYUa4odJHkwtHqysPqh84Je /pjDzdjHWPDjiyWBOf8ZCTV2SiSY99ep4aRYwYDHaLa4ok7LG7RUueeYlKJdGELNqAzy uNM2obFJhBlJ3JM/1RZqp0RIF4Msp09Wp+nYFsfUqteDrMd8mRNbxlHsHfPvzB+rNSgx 0vwA== X-Gm-Message-State: ACgBeo1eA/JV3Q5vs7hmCGkM8xBh4hWLlwdTvkbDD/KTEU3mIb0SK7Zi j9gHkQLpOT/i4eOcuHKsKLItNoyI0rSWwdXExR4= X-Google-Smtp-Source: AA6agR7iu9Q4qBvSGsluGsMvT7c30E9EHVhP7RKMQ/TbeQ8xY17YanHgolM+HB6GBLy5BjpkOyb4P/bp5E8QX511V/A= X-Received: by 2002:aa7:8f0a:0:b0:52d:8135:64e0 with SMTP id x10-20020aa78f0a000000b0052d813564e0mr13196542pfr.0.1659520709538; Wed, 03 Aug 2022 02:58:29 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::534; envelope-from=owinebar@gmail.com; helo=mail-pg1-x534.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:293008 Archived-At: --00000000000063b75705e5534622 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 31, 2022, 4:22 PM Lynn Winebarger wrote: > On Mon, Jul 25, 2022, 4:11 PM Andrea Corallo wrote: > >> >> BTW I think so far we do not support re-dumping Emacs twice with native >> code. This is not a deep technical limitaiton, it's only because how we >> fixup relative eln paths to support installed and non installed builds, >> we should probably work on this limitation... > > > I still can't figure out why building with native compilation and a > site-load file was producing an error about trying to load an incoherent > ELN file. > I found the problem - when I run make in the src directory, the variables for the ELN and bin destinations are blank, which causes the code in loadup that is supposed to make the compilation unit names into pairs to not bother. Maybe these two variables should get constructed in src/Makefile.in? Running make from the src directory shouldn't result in an unusable dump file. I'd probably make the code in loadup either throw an error or come up with some reasonable default. If you insist on having the final installation specified, then it should just error during the build instead of producing a dump guaranteed to fail when loaded. Otherwise, either use some dummy values or just treat the build directory as the install directory. Lynn --00000000000063b75705e5534622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 31, 2022, 4:22 PM Lynn Winebarger <owinebar@gmail.com> wrote:
=
On Mon, Jul 25, 2022, 4:11 PM Andrea = Corallo <akrl@sdf.org> wrote:
<= br> BTW I think so far we do not support re-dumping Emacs twice with native
code.=C2=A0 This is not a deep technical limitaiton, it's only because = how we
fixup relative eln paths to support installed and non installed builds,
we should probably work on this limitation...

I still can't figure out why b= uilding with native compilation and a site-load file was producing an error= about trying to load an incoherent ELN file.=C2=A0=C2=A0

I found th= e problem - when I run make in the src directory, the variables for the ELN= and bin destinations are blank, which causes the code in loadup that is su= pposed to make the compilation unit names into pairs to not bother.
Maybe these two variables should get constructed in src/Mak= efile.in?=C2=A0 Running make from the src directory shouldn't result in= an unusable dump file.=C2=A0=C2=A0
I'd probably= make the code in loadup either throw an error or come up with some reasona= ble default.=C2=A0 If you insist on having the final installation specified= , then it should just error during the build instead of producing a dump gu= aranteed to fail when loaded.=C2=A0 Otherwise, either use some dummy values= or just treat the build directory as the install directory.

Lynn

--00000000000063b75705e5534622--