Re: Suppressing native compilation (short and long term)

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Fri, Oct 14, 2022, 7:22 PM Andrea Corallo <akrl@sdf.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Lars Ingebrigtsen <larsi@gnus.org>
> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
> liliana.prikler@gmail.com,
> >>   rlb@defaultvalue.org,  emacs-devel@gnu.org, Andrea Corallo <
> akrl@sdf.org>
> >> Date: Thu, 13 Oct 2022 22:57:51 +0200
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > No, it should not happen, because async JIT compilation processes run
> >> > Emacs in batch mode, and async compilation is disabled in batch mode
> >> > (for this very reason).
> >>
> >> As we've covered many times recently -- yes, but no.
> >>
> >> .elc -> .eln generation is off, but trampolines are on, and comp.el
> >> forks an Emacs to generate those, too, I think?  So if the forked Emacs
> >> also needs to generate the same trampoline, you have an infinite
> >> recursion fork bomb.
> >
> > Andrea, how can we prevent that?
>
> Dumb question: can't we just run the spawned compilation processes with
> --no-site-file?
>
> Other option is to break circularity with an ad-hoc global variable set
> in the spawned process.  I've a cooked patch for that but no energy left
> to test it tonight.  If that's the preferred way I can test and push it
> tomorrow.


The cleanest way would be to prepare a dump file specifically for compiling
that is known to work, then use that for the async compiler job with any
required settings passed in the command line.  This would make the system
robust when the system dump file is not limited to just the standard build.

Lynn

[-- Attachment #2: Type: text/html, Size: 2808 bytes --]