Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

2012-01-16 Thread Carmelo AMOROSO
On 16/01/2012 8.53, Khem Raj wrote: > On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO > wrote: >> On 15/01/2012 7.22, Khem Raj wrote: >>> On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj wrote: On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj wrote: > On Fri, Jan 13, 2012 at 3:45 PM, Khem Raj wrot

Re: [PATCH] libc: make system() block SIGCHLD

2012-01-16 Thread Richard Braun
On Sun, Jan 15, 2012 at 06:51:15PM -0500, Mike Frysinger wrote: > On Sunday 15 January 2012 14:36:55 Richard Braun wrote: > > On Sun, Jan 15, 2012 at 10:04:58AM -0500, Rich Felker wrote: > > > Your report is wrong. system is REQUIRED by POSIX to change the signal > > > disposition for SIGCHLD, not

Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

2012-01-16 Thread Carmelo AMOROSO
On 16/01/2012 9.09, Carmelo Amoroso wrote: > On 16/01/2012 8.53, Khem Raj wrote: >> On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO >> wrote: >>> On 15/01/2012 7.22, Khem Raj wrote: On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj wrote: > On Fri, Jan 13, 2012 at 4:13 PM, Khem Raj wrote: >>>

[PATCH] libc: fix signal handling in system()

2012-01-16 Thread Richard Braun
When built without NPTL support (or for a sparc target), the system() function doesn't conform to its specification. Namely, it uses signal() to install/save/restore signal handlers, which may break applications using custom handlers installed with sigaction(). In addition, it resets the SIGCHLD ha

Re: [PATCH] libc: make system() block SIGCHLD

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 04:00:08 Richard Braun wrote: > On Sun, Jan 15, 2012 at 06:51:15PM -0500, Mike Frysinger wrote: > > On Sunday 15 January 2012 14:36:55 Richard Braun wrote: > > > On Sun, Jan 15, 2012 at 10:04:58AM -0500, Rich Felker wrote: > > > > Your report is wrong. system is REQUIRED b

Re: [PATCH] tests: speed up make invocation in test clean and fix verbosity

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 02:40:22 Carmelo AMOROSO wrote: > On 15/01/2012 1.33, Mike Frysinger wrote: > > On Saturday 14 January 2012 19:31:16 Mike Frysinger wrote: > >> On Saturday 14 January 2012 10:10:19 Carmelo AMOROSO wrote: > >>> Test clean can be invoked with -j to exploits parallelism. > >>

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Rich Felker
On Mon, Jan 16, 2012 at 10:54:52AM +0100, Richard Braun wrote: > When built without NPTL support (or for a sparc target), the system() > function doesn't conform to its specification. Namely, it uses signal() > to install/save/restore signal handlers, which may break applications > using custom han

Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

2012-01-16 Thread Carmelo AMOROSO
On 16/01/2012 10.36, Carmelo Amoroso wrote: > On 16/01/2012 9.09, Carmelo Amoroso wrote: >> On 16/01/2012 8.53, Khem Raj wrote: >>> On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO >>> wrote: On 15/01/2012 7.22, Khem Raj wrote: > On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj wrote: >> O

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Khem Raj
On Sat, Nov 26, 2011 at 9:22 PM, Mike Frysinger wrote: > Running `make clean` atm takes like 20 seconds because every subdir > re-evaluates all the toolchain flags.  Add some helpers to automate > the process of setting up variables to cache the result of tests, > as well as the checking of an alr

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Richard Braun
On Mon, Jan 16, 2012 at 09:54:24AM -0500, Rich Felker wrote: > This is the THIRD time I've told you that blocking SIGCHLD rather than > ignoring it is non-conformant, and I provided the relevant citation > (link and quoted): > > The system() function shall ignore the SIGINT and SIGQUIT signals

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Khem Raj
On Mon, Jan 16, 2012 at 10:00 AM, Khem Raj wrote: > On Sat, Nov 26, 2011 at 9:22 PM, Mike Frysinger wrote: >> Running `make clean` atm takes like 20 seconds because every subdir >> re-evaluates all the toolchain flags.  Add some helpers to automate >> the process of setting up variables to cache

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Rich Felker
On Mon, Jan 16, 2012 at 07:05:23PM +0100, Richard Braun wrote: > On Mon, Jan 16, 2012 at 09:54:24AM -0500, Rich Felker wrote: > > This is the THIRD time I've told you that blocking SIGCHLD rather than > > ignoring it is non-conformant, and I provided the relevant citation > > (link and quoted): > >

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 14:58:25 Rich Felker wrote: > OK, I'm dyslexic or something and somehow permuted the signal names > every time I read it. Sorry. I think your approach probably works, but > it also means system() is completely unsafe to use in multi-threaded > programs that handle SIGCHLD.

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 14:17:52 Khem Raj wrote: > On Mon, Jan 16, 2012 at 10:00 AM, Khem Raj wrote: > > On Sat, Nov 26, 2011 at 9:22 PM, Mike Frysinger wrote: > >> Running `make clean` atm takes like 20 seconds because every subdir > >> re-evaluates all the toolchain flags. Add some helpers t

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Khem Raj
On Mon, Jan 16, 2012 at 2:19 PM, Mike Frysinger wrote: > On Monday 16 January 2012 14:17:52 Khem Raj wrote: >> On Mon, Jan 16, 2012 at 10:00 AM, Khem Raj wrote: >> > On Sat, Nov 26, 2011 at 9:22 PM, Mike Frysinger wrote: >> >> Running `make clean` atm takes like 20 seconds because every subdir >

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Khem Raj
On Mon, Jan 16, 2012 at 3:06 PM, Khem Raj wrote: > On Mon, Jan 16, 2012 at 2:19 PM, Mike Frysinger wrote: >> On Monday 16 January 2012 14:17:52 Khem Raj wrote: >>> On Mon, Jan 16, 2012 at 10:00 AM, Khem Raj wrote: >>> > On Sat, Nov 26, 2011 at 9:22 PM, Mike Frysinger wrote: >>> >> Running `make

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 18:06:12 Khem Raj wrote: > On Mon, Jan 16, 2012 at 2:19 PM, Mike Frysinger wrote: > > On Monday 16 January 2012 14:17:52 Khem Raj wrote: > >> On Mon, Jan 16, 2012 at 10:00 AM, Khem Raj wrote: > >> > On Sat, Nov 26, 2011 at 9:22 PM, Mike Frysinger wrote: > >> >> Running

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 18:53:02 Mike Frysinger wrote: > On Monday 16 January 2012 18:06:12 Khem Raj wrote: > > your code does not handle such a case and unfortunately we use > > --sort-sections alignment in uclibc build > > where ? i don't see it. oh, the flag is "--sort-section alignment".

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Khem Raj
On Mon, Jan 16, 2012 at 5:11 PM, Mike Frysinger wrote: > On Monday 16 January 2012 18:53:02 Mike Frysinger wrote: >> On Monday 16 January 2012 18:06:12 Khem Raj wrote: >> > your code does not handle such a case and unfortunately we use >> > --sort-sections alignment in uclibc build >> >> where ?  

Re: Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

2012-01-16 Thread Khem Raj
On Mon, Jan 16, 2012 at 1:36 AM, Carmelo AMOROSO wrote: > On 16/01/2012 9.09, Carmelo Amoroso wrote: >> On 16/01/2012 8.53, Khem Raj wrote: >>> On Sun, Jan 15, 2012 at 11:46 PM, Carmelo AMOROSO >>> wrote: On 15/01/2012 7.22, Khem Raj wrote: > On Sat, Jan 14, 2012 at 6:10 PM, Khem Raj wr

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Laurent Bercot
> it also means system() is completely unsafe to use in multi-threaded > programs that handle SIGCHLD... Yes, and that's not a problem. system() is a horrible interface anyway, if only because of the automatic shell invocation and parsing; no self-respecting Unix programmer should ever use it. sy

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 20:48:52 Khem Raj wrote: > On Mon, Jan 16, 2012 at 5:11 PM, Mike Frysinger wrote: > > On Monday 16 January 2012 18:53:02 Mike Frysinger wrote: > >> On Monday 16 January 2012 18:06:12 Khem Raj wrote: > >> > your code does not handle such a case and unfortunately we use > >>

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Khem Raj
On Mon, Jan 16, 2012 at 6:12 PM, Mike Frysinger wrote: > > you don't check linker flags via gcc.  you check the linker flags via the > linker.  this is why the cache funcs setup additional variables for use via > the compiler driver. right and one of those additional variables gets set wrongly to

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 04:54:52 Richard Braun wrote: > --- a/libc/stdlib/system.c > +++ b/libc/stdlib/system.c > > + sa.sa_handler = SIG_IGN; > + sigemptyset(&sa.sa_mask); > + sa.sa_flags = 0; this leaves the other fields of sigaction uninitialized. i think we need: if (c

Re: [RFC/PATCH] buildsys: cache build flags in vars

2012-01-16 Thread Mike Frysinger
On Monday 16 January 2012 21:39:34 Khem Raj wrote: > On Mon, Jan 16, 2012 at 6:12 PM, Mike Frysinger wrote: > > you don't check linker flags via gcc. you check the linker flags via the > > linker. this is why the cache funcs setup additional variables for use > > via the compiler driver. > > rig

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Richard Braun
On Mon, Jan 16, 2012 at 10:52:58PM -0500, Mike Frysinger wrote: > this leaves the other fields of sigaction uninitialized. i think we need: > > if (command == 0) > return 1; > > + memset(&sa, 0, sizeof(sa)); > sa.sa_handler = SIG_IGN; > sigemptyset(&sa.sa_mas

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Mike Frysinger
On Tuesday 17 January 2012 01:38:57 Richard Braun wrote: > On Mon, Jan 16, 2012 at 10:52:58PM -0500, Mike Frysinger wrote: > > this leaves the other fields of sigaction uninitialized. i think we need: > > if (command == 0) > > return 1; > > > > + memset(&sa, 0, sizeof(sa)); > >

Re: [PATCH] libc: fix signal handling in system()

2012-01-16 Thread Richard Braun
On Tue, Jan 17, 2012 at 03:03:19AM +0100, Laurent Bercot wrote: > Yes, and that's not a problem. system() is a horrible interface > anyway, if only because of the automatic shell invocation and > parsing; no self-respecting Unix programmer should ever use it. > system() needs to be implemented for