[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GMAKE 3.81 vs GMAKE 4.2

From: Paul Smith
Subject: Re: GMAKE 3.81 vs GMAKE 4.2
Date: Sat, 21 May 2022 19:27:05 -0400
User-agent: Evolution 3.44.1 (by

On Sat, 2022-05-21 at 08:37 +0530, nikhil jain wrote:
> Also, fatal error handler in commands.C gets called multiple times. I
> believe it is getting called for each parallel make process the
> parent has invoked.

Certainly.  When you press ^C make will propagate that signal to all
its children so that any compile commands, etc. are properly killed. 
This is an absolute requirement: you don't want your compiler to keep
running after you've killed make!

This means every sub-make (which is just another recipe to run, to
make) will also receive a SIGINT.

> 1) why the die() function is not getting called after a ctrl+c ?

Sorry, I misread the code.  I thought that the fatal function would
invoke die() (eventually) but I see now that that only happens if it
fails to kill itself the "normal" way.

So make will exit through die() for "normal" exits and through the
fatal function for exits caused by signals (like ^C).  Two different

> 2) why I am not able to printf anything in fatal error handler in
> commands.c ? I do printf but it doesn’t print on the screen. The
> stdout is gone?

This method is invoked inside a signal handler.  You cannot, generally,
use standard C runtime functions such as printf() inside a signal
handler.  Because a signal is asynchronous, it could interrupt ANY
operation including right in the middle of a malloc() call or free() or
some other printf(), etc. and you can't assume anything about the state
of the program.

There are a limited number of system calls you can invoke from within a
signal handler.  Knowing how to write good signal handler code is an
entire area of study and not related to GNU make really.  There are
docs and tutorials on it out there.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]