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: Suppressing native compilation (short and long term) Date: Sun, 02 Oct 2022 20:44:39 +0300 Message-ID: <83wn9iyvaw.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> <834jwnbi6c.fsf@gnu.org> <87mtafnun5.fsf@trouble.defaultvalue.org> <83sfk6ahty.fsf@gnu.org> <87zgeem8iq.fsf@trouble.defaultvalue.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30210"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org To: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 19:47:06 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 1of33R-0007en-J1 for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 19:47:05 +0200 Original-Received: from localhost ([::1]:57710 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of33Q-0002tw-0B for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 13:47:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of31E-0001H4-Na for emacs-devel@gnu.org; Sun, 02 Oct 2022 13:44:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43900) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of31D-0007nP-Vj; Sun, 02 Oct 2022 13:44:48 -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=m83kvwgTzpS7ds13dkhaT5g54vy1bVnu0W5dF9uvhCo=; b=hlLXJuw5drmw mVRlPRoAH4EdPYBSGRH7W66zN0mgjg0WzRfa1e8cop17isLlveB0uVHXzHLI1VwN3w7mcMcdwIAc3 sIVkSY+1r+mv01+YsYlWMUMl68XTFJruLPqWOYiQtYN7vvv78zrU2kA4qqtfu2tzTnSRK5Y8AMbXR CqOyzlaz5/v4afjbnVidB7PzhmlERYA3vqI1RjfPuJluhT40jEnasSmU34uRWf9iHYg3yY6RbJI4U AhHSNlvlJxrm0nnkLG/NvmfvAmeEhG925WQyK0SzgYuHtwR70JaZgzCdd+uuBlgdOMAUc3uunXXJ3 Y7+rNRYLjGO+kCqswpoSPg==; Original-Received: from [87.69.77.57] (port=1334 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 1of31D-0001PD-EH; Sun, 02 Oct 2022 13:44:47 -0400 In-Reply-To: <87zgeem8iq.fsf@trouble.defaultvalue.org> (message from Rob Browning on Sun, 02 Oct 2022 12:37:33 -0500) 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:296661 Archived-At: > From: Rob Browning > Cc: david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org > Date: Sun, 02 Oct 2022 12:37:33 -0500 > > We've also for a long time made the emacs-el package (containing all the > .el files) optional for similar reasons (constrained environments), but > we recently had to start requiring it because (not sure why yet) emacs > just crashes in some situations when the .el files aren't available and > when native compilation is enabled. Loading of natively-compiled files cannot work if the source files aren't accessible, because loading a .eln file involves verifying that it was produced from that particular .el file. (The .el file can be compressed if Emacs was compiled with zlib support.) But Emacs should not "crash" if the *.el files aren't available, it should simply refuse to load any *.eln files and load the *.elc files instead. That produces many warnings, of course, but I hope your users don't consider that "crashing". > If it hasn't already been fixed in 28.2 (haven't tested yet), it'd be > nice if we could eventually track that down and then switch emacs-el > back to optional (back to "suggested" in Debian dependency parlance). It isn't a bug, but intended behavior. If we want to remove this dependency, some non-trivial ideas about reworking the current load procedure should emerge. I don't thin we have any such ideas at this time.