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

2022-11-02 Thread 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

Re: FreeBSD 13.1-RELEASE make version

2022-11-02 Thread 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

Re: FreeBSD 13.1-RELEASE $< and $^

2022-11-02 Thread 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

Re: [PATCH] Bad timestamps on MinGW32

2022-11-02 Thread 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

Re: [PATCH] Bad timestamps on MinGW32

2022-11-02 Thread 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 >

Re: [PATCH] Bad timestamps on MinGW32

2022-11-02 Thread 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,

Re: [PATCH] Bad timestamps on MinGW32

2022-11-02 Thread 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

[PATCH] Bad timestamps on MinGW32

2022-11-02 Thread 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

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

2022-11-02 Thread 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

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

2022-11-02 Thread 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

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

2022-11-02 Thread 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

[bug #63248] Ignore sigpipe.

2022-11-02 Thread 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

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

2022-11-02 Thread 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

Re: [bug #63248] Ignore sigpipe.

2022-11-02 Thread 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

[bug #63248] Ignore sigpipe.

2022-11-02 Thread 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

[bug #63248] Ignore sigpipe.

2022-11-02 Thread 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:

Re: FreeBSD 13.1-RELEASE make version

2022-11-02 Thread 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 $^

2022-11-02 Thread 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

Re: FreeBSD 13.1-RELEASE $< and $^

2022-11-02 Thread 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.