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