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: Suppressing native compilation (short and long term) Date: Wed, 28 Sep 2022 12:52:59 +0000 Message-ID: References: <87ill8paw7.fsf@trouble.defaultvalue.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="29702"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 28 16:02: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 1odXdZ-0007V8-VQ for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 16:02:09 +0200 Original-Received: from localhost ([::1]:47042 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odXdY-0002dd-M2 for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 10:02:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53136) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odWYk-0007Zm-OX for emacs-devel@gnu.org; Wed, 28 Sep 2022 08:53:07 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:61593) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odWYi-00021r-Ax for emacs-devel@gnu.org; Wed, 28 Sep 2022 08:53: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 28SCqxgR003435 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 28 Sep 2022 12:52:59 GMT In-Reply-To: <87ill8paw7.fsf@trouble.defaultvalue.org> (Rob Browning's message of "Tue, 27 Sep 2022 20:04:24 -0500") 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 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:296397 Archived-At: Hi Rob, Rob Browning writes: > Perhaps relevant in other contexts, but at least in the context of > Debian work, we'd like to be able to suppress all native compilation in > some contexts, or more specifically all writes to HOME (or really, to > avoid any implicit file manipulations[1]). > > One key case is package builds and package installs (whether the emacs > packages themselves, or any of the various emacs add-on packages > (e.g. elpa-*)). > > For package builds, HOME is typically set to /nonexistent (or similar), > and for package installs we don't want the install commands (preinst, > postinst, etc.), which are running as root, to write anything to /root/. > > It's also been suggested by some users that they might like to have a > supported way to disable native compilation (even when it's the system > default), in order to avoid the unpredictable cpu and/or battery cost > sometimes. Of course, assuming we eventually augment debian's current > emacs infrastructure to generate system-level .eln files during (add-on) > package installs, in addition to the .elc files it currently produces, > much of that concern for debian and its derivatives might recede. This is what `native-comp-deferred-compilation' does. Well except for trampolines but this is extremly light as cpu/energy cost. > In any case, I noticed that there is a no-native-compile variable, and > wondered if (in the short term), I might be able to craft a (possibly > debian-specific for now) way to disable native compilation across the > board. > > Just to see, I changed no-native-compile to default to > > (getenv "DEBIAN_EMACS_DISABLE_NATIVE_COMPILATION") > > instead of nil, and then set that in the environment, but the ebib > package tests (which set HOME=/nonexistent) still crashed (as had been > originally reported here https://bugs.debian.org/1020191). > > The crash was in comp-trampoline-compile, and after a bit of > investigation I wondered if it might be possible to fix the problem (at > least approximately) by adding a no-native-compile clause to the > comp-subr-trampoline-install guard like this: > > (defun comp-subr-trampoline-install (subr-name) > "Make SUBR-NAME effectively advice-able when called from native code." > (unless (or no-native-compilation ; this is new > (null comp-enable-subr-trampolines) > (memq subr-name native-comp-never-optimize-functions) > (gethash subr-name comp-installed-trampolines-h)) > ...)) A native compiled Emacs needs to compile a trampoline each time a primitive is redefined or advised. If we disable this mechanism ATM we cannot guarantee Emacs to function correctly. > That did allow the package tests to run successfully. > > So two questions: > > - As possibly just a short term, debian-specific fix, do those changes > sound plausible, or are there other things we're missing (I might > guess yes)? IMO the suggested change is not okay for the reason mentioned above sorry :/ > > - Longer term, might it make sense to have some emacs-proper way to > completely disable native compilation from the outside, either via > environment variable, argument, or something else, for situations > like this? > > [1] For add-on packages (e.g. elpa-*, etc.), we want to explicitly build > the local .elc files (at least) during the install, but we don't > want to write to any other unexpected locations. > > Thanks IIUC the issue is when Emacs is run as root (I didn't know Debian does that for installing packages!). The workaround I'd suggest is to target a temporary HOME and clean it afterwards with its eln-cache (if this is viable). Best Regards Andrea