RE: GNUmake v4.4 port on Solaris with gcc 9.5.0

[Christian Jullien]

I'm sorry, I was also compiling less 608 and I've read the wrong PuTTY window.

Here is the correct one for make v4.4 on Solaris 10 with gcc 9.5.0:


gcc -DHAVE_CONFIG_H -I. -I../src   -I/usr/local/include  -Wno-cast-qual 
-Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef 
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion 
-Wimplicit-fallthrough -Wno-pedantic -Wno-sign-conversion -Wno-type-limits 
-Wno-unsuffixed-float-constants -g -O2 -MT libgnu_a-concat-filename.o -MD -MP 
-MF .deps/libgnu_a-concat-filename.Tpo -c -o libgnu_a-concat-filename.o `test 
-f 'concat-filename.c' || echo './'`concat-filename.c
concat-filename.c: In function 'concatenated_filename':
concat-filename.c:69:7: warning: implicit declaration of function 'stpcpy' 
[-Wimplicit-function-declaration]
   69 |   p = stpcpy (p, filename);
  |   ^~
concat-filename.c:69:7: warning: incompatible implicit declaration of built-in 
function 'stpcpy'


-Original Message-
From: Christian Jullien [mailto:eli...@orange.fr] 
Sent: Thursday, November 03, 2022 06:51
To: psm...@gnu.org; jull...@eligis.com; make-...@gnu.org
Subject: GNUmake v4.4 port on Solaris with gcc 9.5.0

Hi again,

If you care, here are few warnings I've got compiling v4.4 on Solaris 10 using 
gcc 9.5.0 which is the latest gcc version supported by Solaris 10.

[jullien@pastre]less-608$ ./configure; make
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for library containing strerror... none required
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/local/bin/grep
checking for egrep... /usr/local/bin/grep -E
checking whether gcc needs -traditional... no
checking for a BSD-compatible install... /usr/local/bin/install -c
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for tgoto in -ltinfo... no
checking for tgoto in -ltinfow... no
checking for initscr in -lxcurses... no
checking for initscr in -lncursesw... no
checking for initscr in -lncurses... yes
checking for initscr in -lcurses... yes
checking for tgetent in -ltermcap... yes
checking for tgetent in -ltermlib... yes
checking for library containing regcmp... none required
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking termcap.h usability... no
checking termcap.h presence... no
checking for termcap.h... no
checking termio.h usability... yes
checking termio.h presence... yes
checking for termio.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking for unistd.h... (cached) yes
checking values.h usability... yes
checking values.h presence... yes
checking for values.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/stream.h usability... yes
checking sys/stream.h presence... yes
checking for sys/stream.h... yes
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking whether stat file-mode macros are broken... no
checking for an ANSI C-conforming const... yes
checking for off_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for working terminal libraries... using -lncurses
checking for off_t... (cached) yes
checking for void... yes
checking for const... yes
checking for time_t... yes
checking for st_ino in struct stat... yes
checking for procfs... no
checking for ANSI function prototypes... yes
checking return type of signal handlers... void
checking for fchmod... yes
checking for fsync... yes
checking for nanosleep... no
checking for p

Re: [PATCH] Bad timestamps on MinGW32

[Orgad Shaneh]

On Thu, Nov 3, 2022 at 8:07 AM Eli Zaretskii  wrote:
>
> > From: Orgad Shaneh 
> > Date: Wed, 2 Nov 2022 22:14:26 +0200
> > Cc: bug-make@gnu.org
> >
> > On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii  wrote:
> > > > Fix by enabling _stat64 also for MinGW.
> > >
> > > Thanks, but this cannot be done for all MinGW builds.  There's
> > > mingw.org's MinGW (which is what I use), and its default is to use
> > > 32-bit time_t values.  If you use this change with that MinGW, Make
> > > will likely crash at run time, because various libraries it is linked
> > > against use a different time_t in stat calls.
> >
> > Hi, and thanks for the prompt reply.
> >
> > Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> > platform?
>
> Indeed, it doesn't currently.  But I wouldn't count on that, some
> future version could introduce it.

Is mingw.org still active? Where can I get it?

> > Or that it doesn't support _stat64?
>
> _stat64 _is_ supported, but it isn't the default.  So if a program
> needs to use _stat64, it can only be safely linked against libraries
> that were also compiled with stat redirected to _stat64, otherwise you
> cannot safely pass 'struct stat' variables and pointers between the
> program and those libraries.  And since _stat64 is not the default,
> the chance that libraries against which you link used it is very
> small, practically nil.

* Which libraries?
* Why should we care what other libraries do? Do we pass struct stat
to other libraries, or only to system functions?

- Orgad

Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Jeffrey Walton 
> Date: Wed, 2 Nov 2022 16:22:51 -0400
> Cc: bug-make@gnu.org
> 
> You might also be interested in __MINGW64__.

That's possible, but AFAIK it is only defined after including some
headers; the compiler itself doesn't define it.  Caveat emptor.

> I don't think it's a good idea to try to use MinGW or compiler
> versions as a proxy for 32- or 64-bit time_t. Things are in flux to
> fix the y2038 problem. The debian-arm and debian-powerpc lists are
> having discussions about it now. You will surely encounter 64-bit
> time_t on 32-bit machines eventually.

32-bit Windows have 64-bit time_t variant, but to use it you need to
redirect some function to non-default variants.  'stat' is on of those
functions.

> A first class configure test that checks for the size of time_t will
> probably be your best choice.

As I explained in my other mail, the issue here is not to know whether
the platform _can_ support 64-bit time data types, the issue is what
is the default, because libraries against Make is linked were most
probably compiled with that default.

Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Orgad Shaneh 
> Date: Wed, 2 Nov 2022 22:14:26 +0200
> Cc: bug-make@gnu.org
> 
> On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii  wrote:
> > > Fix by enabling _stat64 also for MinGW.
> >
> > Thanks, but this cannot be done for all MinGW builds.  There's
> > mingw.org's MinGW (which is what I use), and its default is to use
> > 32-bit time_t values.  If you use this change with that MinGW, Make
> > will likely crash at run time, because various libraries it is linked
> > against use a different time_t in stat calls.
> 
> Hi, and thanks for the prompt reply.
> 
> Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> platform?

Indeed, it doesn't currently.  But I wouldn't count on that, some
future version could introduce it.

> Or that it doesn't support _stat64?

_stat64 _is_ supported, but it isn't the default.  So if a program
needs to use _stat64, it can only be safely linked against libraries
that were also compiled with stat redirected to _stat64, otherwise you
cannot safely pass 'struct stat' variables and pointers between the
program and those libraries.  And since _stat64 is not the default,
the chance that libraries against which you link used it is very
small, practically nil.

The same goes for MinGW64, btw: you can only safely redirect stat to
_stat64 there if MinGW64 does that by default.  (I think it does, but
I'm not sure.)

> > So this condition:
> >
> > > -#if defined(_MSC_VER) && _MSC_VER > 1200
> > > +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
> >
> > must be rewritten to catch only MinGW64 builds.  Which would mean a
> > more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.
> 
> I'll try to find something. But first I'll need an answer for the
> previous question, so I know which changes to look for in mingw.

I hope I answered them.

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[anonymous]

Follow-up Comment #1, bug #63307 (project make):

Can confirm the patch posted to the mailing list,
, works for
me to fix this. Thanks for the prompt response.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: FreeBSD 13.1-RELEASE make version

[Kaíque Kandy Koga]

That's right, I am using a different make. Thank you.

On Wed, Nov 2, 2022 at 10:03 AM Paul Smith  wrote:

> On Tue, 2022-11-01 at 18:39 -0300, Kaíque Kandy Koga wrote:
>
> Version is not being displayed on FreeBSD.
>
> [kandy@ ~/a]$ make --version
>
>
> I suspect you are using BSD make, not GNU make.
>
> Please verify which make you are using.
>

Re: FreeBSD 13.1-RELEASE $< and $^

[Kaíque Kandy Koga]

Sorry for bothering. You guys are correct. I am actually using a different
make. Thank you.

On Wed, Nov 2, 2022 at 11:05 AM David A. Wheeler 
wrote:

>
>
> > On Nov 2, 2022, at 9:03 AM, Paul Smith  wrote:
> >
> > On Tue, 2022-11-01 at 18:37 -0300, Kaíque Kandy Koga wrote:
> >> $< and $^ do not seem to work on FreeBSD.
> >
> > I suspect you are using BSD make, not GNU make.
> >
> > Please verify which make you are using.
>
> Agreed. IIRC, on FreeBSD, "make" is BSD make and "gmake" is GNU make.
>
> --- David A. Wheeler
>
>
>

Re: [PATCH] Bad timestamps on MinGW32

[Paul Smith]

On Wed, 2022-11-02 at 16:22 -0400, Jeffrey Walton wrote:
> A first class configure test that checks for the size of time_t will
> probably be your best choice.

Unfortunately we don't (always) run configure on Windows (it's possible
to build GNU make on Windows systems where you can't run configure
because you don't have a POSIX environment).

So, a configure check isn't the best choice.  We'd prefer a
preprocessor test that can detect this situation.

Re: [PATCH] Bad timestamps on MinGW32

[Jeffrey Walton]

On Wed, Nov 2, 2022 at 4:15 PM Orgad Shaneh  wrote:
>
> On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii  wrote:
> > > Fix by enabling _stat64 also for MinGW.
> >
> > Thanks, but this cannot be done for all MinGW builds.  There's
> > mingw.org's MinGW (which is what I use), and its default is to use
> > 32-bit time_t values.  If you use this change with that MinGW, Make
> > will likely crash at run time, because various libraries it is linked
> > against use a different time_t in stat calls.
>
> Hi, and thanks for the prompt reply.
>
> Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
> platform? Or that it doesn't support _stat64? Or something else?
>
> > So this condition:
> >
> > > -#if defined(_MSC_VER) && _MSC_VER > 1200
> > > +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
> >
> > must be rewritten to catch only MinGW64 builds.  Which would mean a
> > more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.
>
> I'll try to find something. But first I'll need an answer for the
> previous question, so I know which changes to look for in mingw.

You might also be interested in __MINGW64__.

I don't think it's a good idea to try to use MinGW or compiler
versions as a proxy for 32- or 64-bit time_t. Things are in flux to
fix the y2038 problem. The debian-arm and debian-powerpc lists are
having discussions about it now. You will surely encounter 64-bit
time_t on 32-bit machines eventually.

A first class configure test that checks for the size of time_t will
probably be your best choice.

Jeff

Re: [PATCH] Bad timestamps on MinGW32

[Orgad Shaneh]

On Wed, Nov 2, 2022 at 7:04 PM Eli Zaretskii  wrote:
> > Fix by enabling _stat64 also for MinGW.
>
> Thanks, but this cannot be done for all MinGW builds.  There's
> mingw.org's MinGW (which is what I use), and its default is to use
> 32-bit time_t values.  If you use this change with that MinGW, Make
> will likely crash at run time, because various libraries it is linked
> against use a different time_t in stat calls.

Hi, and thanks for the prompt reply.

Do you mean that __MINGW_USE_VC2005_COMPAT has no effect on this
platform? Or that it doesn't support _stat64? Or something else?

> So this condition:
>
> > -#if defined(_MSC_VER) && _MSC_VER > 1200
> > +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
>
> must be rewritten to catch only MinGW64 builds.  Which would mean a
> more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.

I'll try to find something. But first I'll need an answer for the
previous question, so I know which changes to look for in mingw.

- Orgad

Re: [PATCH] Bad timestamps on MinGW32

[Eli Zaretskii]

> From: Orgad Shaneh 
> Date: Wed, 2 Nov 2022 18:32:49 +0200
> 
> Commit 01142a53c9d (Add support for intmax_t) added support for 64-bit
> time_t by defining __MINGW_USE_VC2005_COMPAT. But this only works with
> _stat64 as expected. When stat is used on 32-bit systems, it returns a
> bad timestamp (for example, 72586185920376753).
> 
> This triggers the following errors every time make is executed:
> mingw32-make: Warning: File 'Makefile' has modification time 7.3e+16 s
> in the future
> mingw32-make: warning:  Clock skew detected.  Your build may be incomplete.
> 
> and of course, dependencies are completely broken.
> 
> Fix by enabling _stat64 also for MinGW.

Thanks, but this cannot be done for all MinGW builds.  There's
mingw.org's MinGW (which is what I use), and its default is to use
32-bit time_t values.  If you use this change with that MinGW, Make
will likely crash at run time, because various libraries it is linked
against use a different time_t in stat calls.

So this condition:

> -#if defined(_MSC_VER) && _MSC_VER > 1200
> +#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)

must be rewritten to catch only MinGW64 builds.  Which would mean a
more fine-grained testing of the value of __MINGW_MAJOR_VERSION etc.

[PATCH] Bad timestamps on MinGW32

[Orgad Shaneh]

Commit 01142a53c9d (Add support for intmax_t) added support for 64-bit
time_t by defining __MINGW_USE_VC2005_COMPAT. But this only works with
_stat64 as expected. When stat is used on 32-bit systems, it returns a
bad timestamp (for example, 72586185920376753).

This triggers the following errors every time make is executed:
mingw32-make: Warning: File 'Makefile' has modification time 7.3e+16 s
in the future
mingw32-make: warning:  Clock skew detected.  Your build may be incomplete.

and of course, dependencies are completely broken.

Fix by enabling _stat64 also for MinGW.
---
 src/remake.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/remake.c b/src/remake.c
index 4ce3d2a3..83b0b79d 100644
--- a/src/remake.c
+++ b/src/remake.c
@@ -37,7 +37,7 @@ this program.  If not, see
.  */
 #include 
 #include 
 #include 
-#if defined(_MSC_VER) && _MSC_VER > 1200
+#if defined(__MINGW32__) || (defined(_MSC_VER) && _MSC_VER > 1200)
 /* VC7 or later supprots _stat64 to access 64-bit file size. */
 #define STAT _stat64
 #else
--
2.38.1.windows.1

[PATCH] [SV 63307] Reset SIGPIPE in spawned children

[Andreas Schwab]

* configure.ac: Check for posix_spawnattr_setsigdefault.
* src/job.c (child_execute_job): Reset SIGPIPE in the child
process.
* src/job.h (sigpipe_ignored): Declare.
* src/main.c (main): Remember if SIGPIPE was inherited as ignored.
---
 configure.ac |  2 +-
 src/job.c| 24 
 src/job.h|  2 ++
 src/main.c   |  2 +-
 4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 9f688971..30eb2d55 100644
--- a/configure.ac
+++ b/configure.ac
@@ -134,7 +134,7 @@ AC_CHECK_FUNCS([strtoll strdup strndup stpcpy memrchr 
mempcpy umask mkstemp \
 getgroups seteuid setegid setlinebuf setreuid setregid \
 mkfifo getrlimit setrlimit setvbuf pipe strerror strsignal \
 lstat readlink atexit isatty ttyname pselect posix_spawn \
-posix_spawnattr_setsigmask])
+posix_spawnattr_setsigmask posix_spawnattr_setsigdefault])
 
 # We need to check declarations, not just existence, because on Tru64 this
 # function is not declared without special flags, which themselves cause
diff --git a/src/job.c b/src/job.c
index b78f279c..4f32f0f7 100644
--- a/src/job.c
+++ b/src/job.c
@@ -261,6 +261,10 @@ unsigned long job_counter = 0;
 /* Number of jobserver tokens this instance is currently using.  */
 
 unsigned int jobserver_tokens = 0;
+
+/* Whether SIGPIPE was ignored on entry.  */
+
+int sigpipe_ignored;
 
 
 #ifdef WINDOWS32
@@ -2305,6 +2309,12 @@ child_execute_job (struct childbase *child, int 
good_stdin, char **argv)
   /* We are the child.  */
   unblock_all_sigs ();
 
+  /* Unignore SIPIPE.  */
+#ifdef SIGPIPE
+  if (!sigpipe_ignored)
+bsd_signal (SIGPIPE, SIG_DFL);
+#endif
+
 #ifdef SET_STACK_SIZE
   /* Reset limits, if necessary.  */
   if (stack_limit.rlim_cur)
@@ -2347,6 +2357,20 @@ child_execute_job (struct childbase *child, int 
good_stdin, char **argv)
   }
 #endif /* have posix_spawnattr_setsigmask() */
 
+  /* Unignore SIGPIPE.  */
+#ifdef HAVE_POSIX_SPAWNATTR_SETSIGDEFAULT
+  if (!sigpipe_ignored)
+{
+  sigset_t mask;
+  sigemptyset (&mask);
+  sigaddset (&mask, SIGPIPE);
+  r = posix_spawnattr_setsigdefault (&attr, &mask);
+  if (r != 0)
+   goto cleanup;
+  flags |= POSIX_SPAWN_SETSIGDEF;
+}
+#endif
+
   /* USEVFORK can give significant speedup on systems where it's available.  */
 #ifdef POSIX_SPAWN_USEVFORK
   flags |= POSIX_SPAWN_USEVFORK;
diff --git a/src/job.h b/src/job.h
index 14a9984d..b0352bd7 100644
--- a/src/job.h
+++ b/src/job.h
@@ -88,5 +88,7 @@ pid_t exec_command (char **argv, char **envp);
 
 void unblock_all_sigs (void);
 
+extern int sigpipe_ignored;
+
 extern unsigned int job_slots_used;
 extern unsigned int jobserver_tokens;
diff --git a/src/main.c b/src/main.c
index eec93656..3b39e9fe 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1184,7 +1184,7 @@ main (int argc, char **argv, char **envp)
 
   /* Don't die if our stdout sends us SIGPIPE.  */
 #ifdef SIGPIPE
-  bsd_signal (SIGPIPE, SIG_IGN);
+  sigpipe_ignored = bsd_signal (SIGPIPE, SIG_IGN) == SIG_IGN;
 #endif
 
 #ifdef HAVE_ATEXIT
-- 
2.38.1


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] [SV 63307] Unignore SIGPIPE in spawned children

[Philip Guenther]

make should note whether SIGPIPE is ignored on entry and, if so, then it
should leave it ignored when it invokes other programs and not
unconditionally set SIGPIPE to SIGDFL.

Philip Guenther


On Wed, Nov 2, 2022 at 6:29 AM Andreas Schwab  wrote:

> * configure.ac: Check for posix_spawnattr_setsigdefault.
> * src/job.c (child_execute_job): Set SIGPIPE to default in the
> child process.
> ---
>  configure.ac |  2 +-
>  src/job.c| 18 ++
>  2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 9f688971..30eb2d55 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -134,7 +134,7 @@ AC_CHECK_FUNCS([strtoll strdup strndup stpcpy memrchr
> mempcpy umask mkstemp \
>  getgroups seteuid setegid setlinebuf setreuid setregid \
>  mkfifo getrlimit setrlimit setvbuf pipe strerror
> strsignal \
>  lstat readlink atexit isatty ttyname pselect posix_spawn \
> -posix_spawnattr_setsigmask])
> +posix_spawnattr_setsigmask posix_spawnattr_setsigdefault])
>
>  # We need to check declarations, not just existence, because on Tru64 this
>  # function is not declared without special flags, which themselves cause
> diff --git a/src/job.c b/src/job.c
> index b78f279c..621ff899 100644
> --- a/src/job.c
> +++ b/src/job.c
> @@ -2305,6 +2305,11 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
>/* We are the child.  */
>unblock_all_sigs ();
>
> +  /* Unignore SIPIPE.  */
> +#ifdef SIGPIPE
> +  bsd_signal (SIGPIPE, SIG_DFL);
> +#endif
> +
>  #ifdef SET_STACK_SIZE
>/* Reset limits, if necessary.  */
>if (stack_limit.rlim_cur)
> @@ -2347,6 +2352,19 @@ child_execute_job (struct childbase *child, int
> good_stdin, char **argv)
>}
>  #endif /* have posix_spawnattr_setsigmask() */
>
> +  /* Unignore SIGPIPE.  */
> +#ifdef HAVE_POSIX_SPAWNATTR_SETSIGDEFAULT
> +  {
> +sigset_t mask;
> +sigemptyset (&mask);
> +sigaddset (&mask, SIGPIPE);
> +r = posix_spawnattr_setsigdefault (&attr, &mask);
> +if (r != 0)
> +  goto cleanup;
> +flags |= POSIX_SPAWN_SETSIGDEF;
> +  }
> +#endif
> +
>/* USEVFORK can give significant speedup on systems where it's
> available.  */
>  #ifdef POSIX_SPAWN_USEVFORK
>flags |= POSIX_SPAWN_USEVFORK;
> --
> 2.38.1
>
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
>

[PATCH] [SV 63307] Unignore SIGPIPE in spawned children

[Andreas Schwab]

* configure.ac: Check for posix_spawnattr_setsigdefault.
* src/job.c (child_execute_job): Set SIGPIPE to default in the
child process.
---
 configure.ac |  2 +-
 src/job.c| 18 ++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 9f688971..30eb2d55 100644
--- a/configure.ac
+++ b/configure.ac
@@ -134,7 +134,7 @@ AC_CHECK_FUNCS([strtoll strdup strndup stpcpy memrchr 
mempcpy umask mkstemp \
 getgroups seteuid setegid setlinebuf setreuid setregid \
 mkfifo getrlimit setrlimit setvbuf pipe strerror strsignal \
 lstat readlink atexit isatty ttyname pselect posix_spawn \
-posix_spawnattr_setsigmask])
+posix_spawnattr_setsigmask posix_spawnattr_setsigdefault])
 
 # We need to check declarations, not just existence, because on Tru64 this
 # function is not declared without special flags, which themselves cause
diff --git a/src/job.c b/src/job.c
index b78f279c..621ff899 100644
--- a/src/job.c
+++ b/src/job.c
@@ -2305,6 +2305,11 @@ child_execute_job (struct childbase *child, int 
good_stdin, char **argv)
   /* We are the child.  */
   unblock_all_sigs ();
 
+  /* Unignore SIPIPE.  */
+#ifdef SIGPIPE
+  bsd_signal (SIGPIPE, SIG_DFL);
+#endif
+
 #ifdef SET_STACK_SIZE
   /* Reset limits, if necessary.  */
   if (stack_limit.rlim_cur)
@@ -2347,6 +2352,19 @@ child_execute_job (struct childbase *child, int 
good_stdin, char **argv)
   }
 #endif /* have posix_spawnattr_setsigmask() */
 
+  /* Unignore SIGPIPE.  */
+#ifdef HAVE_POSIX_SPAWNATTR_SETSIGDEFAULT
+  {
+sigset_t mask;
+sigemptyset (&mask);
+sigaddset (&mask, SIGPIPE);
+r = posix_spawnattr_setsigdefault (&attr, &mask);
+if (r != 0)
+  goto cleanup;
+flags |= POSIX_SPAWN_SETSIGDEF;
+  }
+#endif
+
   /* USEVFORK can give significant speedup on systems where it's available.  */
 #ifdef POSIX_SPAWN_USEVFORK
   flags |= POSIX_SPAWN_USEVFORK;
-- 
2.38.1


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[bug #63248] Ignore sigpipe.

[anonymous]

Follow-up Comment #5, bug #63248 (project make):

Thanks, I have submitted #63307 for it.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63307] make 4.4 passes ignored SIGPIPE on to children

[anonymous]

URL:
  

 Summary: make 4.4 passes ignored SIGPIPE on to children
 Project: make
   Submitter: None
   Submitted: Wed 02 Nov 2022 03:12:02 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Wed 02 Nov 2022 03:12:02 PM UTC By: Anonymous
Test case:

$ cat Makefile
all:
(sleep 1; echo foo; echo bar >&2) | :
$ make-4.3
(sleep 1; echo foo; echo bar >&2) | :
$ make-4.4
(sleep 1; echo foo; echo bar >&2) | :
/bin/sh: 1: echo: Broken pipe
bar
$ 

I asked in #63248 whether this was intentional. It was not, so here is a bug
for it. What happens in make 4.3 is the sleep makes it so that the "echo foo"
is extremely unlikely to start until the : has already terminated. Then, when
"echo foo" attempts to write, the whole shell process receives SIGPIPE. What
happens in make 4.4 is that the shell process does not receive SIGPIPE and
continues processing.

This causes SuSE bug 33947
(https://lists.gnu.org/archive/html/bug-diffutils/2019-01/msg0.html,
diffutils testsuite failure when SIGPIPE is ignored) to appear in environments
where it previously did not, after upgrading to make 4.4.







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [bug #63248] Ignore sigpipe.

[Andreas Schwab]

On Nov 02 2022, Paul D. Smith wrote:

> Make should not pass the ignore to children; if it does that's a bug in make
> and should be reported.

I don't see anything that unignores SIGPIPE.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[bug #63248] Ignore sigpipe.

[anonymous]

Follow-up Comment #3, bug #63248 (project make):

Hi, this change does not just mean make ignores SIGPIPE, it also means
everything spawned by make ignores SIGPIPE. Is this intentional? I am seeing a
failure in another package as a result of this after updating to make 4.4 and
do not know whether to submit this as a make bug, or as a bug against that
package.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63248] Ignore sigpipe.

[Paul D. Smith]

Follow-up Comment #4, bug #63248 (project make):

Make should not pass the ignore to children; if it does that's a bug in make
and should be reported.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: FreeBSD 13.1-RELEASE make version

[Paul Smith]

On Tue, 2022-11-01 at 18:39 -0300, Kaíque Kandy Koga wrote:
> Version is not being displayed on FreeBSD.
> 
> > [kandy@ ~/a]$ make --version

I suspect you are using BSD make, not GNU make.

Please verify which make you are using.

Re: FreeBSD 13.1-RELEASE $< and $^

[David A. Wheeler]

> On Nov 2, 2022, at 9:03 AM, Paul Smith  wrote:
> 
> On Tue, 2022-11-01 at 18:37 -0300, Kaíque Kandy Koga wrote:
>> $< and $^ do not seem to work on FreeBSD.
> 
> I suspect you are using BSD make, not GNU make.
> 
> Please verify which make you are using.

Agreed. IIRC, on FreeBSD, "make" is BSD make and "gmake" is GNU make.

--- David A. Wheeler

Re: FreeBSD 13.1-RELEASE $< and $^

[Paul Smith]

On Tue, 2022-11-01 at 18:37 -0300, Kaíque Kandy Koga wrote:
> $< and $^ do not seem to work on FreeBSD.

I suspect you are using BSD make, not GNU make.

Please verify which make you are using.