From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: --with-native-compilation build failure on 32-bit systems Date: Mon, 08 Aug 2022 07:44:43 +0000 Message-ID: References: <86k07nl9qe.fsf@phe.ftfl.ca> <87bksyc36k.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38262"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , Joseph Mingrone , emacs-devel , emacs@freebsd.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 09:46:39 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 1oKxTC-0009iT-P4 for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 09:46:38 +0200 Original-Received: from localhost ([::1]:55052 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKxTB-0003TX-3T for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 03:46:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43566) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKxRi-0002kk-Eu for emacs-devel@gnu.org; Mon, 08 Aug 2022 03:45:06 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:61757) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKxRg-00076M-IS for emacs-devel@gnu.org; Mon, 08 Aug 2022 03:45:06 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2787igIc010445 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 8 Aug 2022 07:44:43 GMT In-Reply-To: (Lynn Winebarger's message of "Fri, 5 Aug 2022 11:16:39 -0400") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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:293244 Archived-At: Lynn Winebarger writes: > On Fri, Aug 5, 2022, 10:42 AM Andrea Corallo wrote: > > Andrea Corallo writes: > > > Lars Ingebrigtsen writes: > > > >> Joseph Mingrone writes: > >> > >>> Could 261d6af have broken --with-native-compilation builds on 32-bit > >>> systems? This is what I see building in a clean FreeBSD/i386 13.0 > >>> jail using 261d6af: > >>> http://pkg.ftfl.ca/data/13i386-default/2022-08-04_22h38m28s/logs/errors/emacs-devel-29.0.50.20220804,2.log > >> > >> I guess these are the error messages? > >> > >> emacs: Trying to load incoherent dumped eln file > >> > /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-261d6af/native-lisp/29.0.50-7cc1a43d/preloaded/ediff-hook-0b92f1a2-f843c8a0.eln > > >> > >> I don't know what that means; Andrea added to the CCs. > > > > It's very surprising to see 261d6af causing this side effect, at least I > > don't see why should effect the 32bit build only. > > > > I'm trying to reproduce it on my 32bit env. > > I confirm the build it's broken on my 32bit env as well, (but not on the > 64 one). > > Loading the second dump, while we are relocating the ediff-hook > compilation unit, we realize (@ pdumper.c:5304) that its file field is > not a cons as expected but just a string. > > Now the question is why this is not fixed-up in loadup.el:477 as for the > other compilation units? > > Are you sure it's actually fixed up in the other compilation units? Indeed, otherwise an error is signaled. > This problem should be signaled by loadup if there are any NCUs it does not fix up. It would be a lot easier to diagnose > the problem from there. loadup is in charge of fixing up on all CU's file fields, and indeed if something goes wrong in that code an error is signaled. But evidently this is not the case, so there's something more to understand. Regards Andrea