If the active compiler or flags have already defined _FORTIFY_SOURCE,
don't go overriding that. Otherwise we get a lot of spew about the
flag being redefined.
* configure.ac (FORTIFY_SOURCE): Check if _FORTIFY_SOURCE is defined.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Mike Frysinger wrote:
> If the active compiler or flags have already defined _FORTIFY_SOURCE,
> don't go overriding that. Otherwise we get a lot of spew about the
> flag being redefined.
>
> * configure.ac (FORTIFY_SOURCE): Check if _FORTIFY_SOURCE is defined.
> ---
> configure.ac | 2 +-
> 1 fil
On Tuesday 23 October 2012 15:26:14 Jim Meyering wrote:
> Mike Frysinger wrote:
> > If the active compiler or flags have already defined _FORTIFY_SOURCE,
> > don't go overriding that. Otherwise we get a lot of spew about the
> > flag being redefined.
> >
> > * configure.ac (FORTIFY_SOURCE): Check
On 10/23/2012 01:50 PM, Mike Frysinger wrote:
> On Tuesday 23 October 2012 15:26:14 Jim Meyering wrote:
>> Mike Frysinger wrote:
>>> If the active compiler or flags have already defined _FORTIFY_SOURCE,
>>> don't go overriding that. Otherwise we get a lot of spew about the
>>> flag being redefined
if i look at vanilla coreutils-8.20, i see:
Makefile.in:man/uname.1: src/uname.c
which seems to have originated from man/local.mk, but munged:
man/uname.1: src/uname
this causes parallel build problems because man/uname.1 generation can get
scheduled before src/uname has been linked. ea
On 10/23/2012 11:27 PM, Mike Frysinger wrote:
if i look at vanilla coreutils-8.20, i see:
Makefile.in:man/uname.1: src/uname.c
which seems to have originated from man/local.mk, but munged:
man/uname.1: src/uname
this causes parallel build problems because man/uname.1 generation can get
