On Wed, May 8, 2013 at 1:17 AM, Allan McRae wrote:
> Our distribution packages are compiled with:
>
> CPPFLAGS="-D_FORTIFY_SOURCE=2"
> CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
> --param=ssp-buffer-size=4"
>
> So when both CPPFLAGS and CFLAGS are passed there is no issue.
I
On 05/08/2013 07:00 AM, Zack Weinberg wrote:
> I think the quick fix from your end is to move -D_FORTIFY_SOURCE to
> CFLAGS (and presumably also CXXFLAGS).
Another possibility is to append -O2 to CPPFLAGS. The point is that
-O2 should always be used if -D_FORTIFY_SOURCE is.
> I note that Debian
On Wed, May 8, 2013 at 10:15 AM, Paul Eggert wrote:
> On 05/08/2013 07:00 AM, Zack Weinberg wrote:
>> I note that Debian has patched this warning out of their (just now
>> appeared in unstable) glibc 2.17.
>
> Sounds like a win to me. Maybe I should file a glibc bug report
> upstream
If you
On Wednesday 08 May 2013 01:01:06 Paul Eggert wrote:
> On 05/07/2013 08:49 PM, Anatol Pomozov wrote:
> > recent versions of glibc produces a
> > warning when it compiles apps with _FORTIFY_SOURCE but without -O2
>
> That's a real problem, which will break lots of things.
i complained when the cha
On 05/08/2013 04:00 PM, Zack Weinberg wrote:
On Wed, May 8, 2013 at 1:17 AM, Allan McRae wrote:
Our distribution packages are compiled with:
CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4"
So when both CPPFLAGS and CFL
Hi
On Wed, May 8, 2013 at 10:20 AM, Ralf Corsepius wrote:
> On 05/08/2013 04:00 PM, Zack Weinberg wrote:
>
>> On Wed, May 8, 2013 at 1:17 AM, Allan McRae wrote:
>>
>>> Our distribution packages are compiled with:
>>>
>>> CPPFLAGS="-D_FORTIFY_SOURCE=2"
>>> CFLAGS="-march=x86-64 -mtune=generic -
On 05/08/13 11:26, Anatol Pomozov wrote:
> Why autoconf uses CPPFLAGS
> (and not CPPFLAGS+CXXFLAGS) for headers discovery?
It's a long story, but basically autoconf used to invoke
just the preprocessor to test for header existence, partly
on the grounds of making 'configure' go faster. That turns
On 09/05/13 07:11, Paul Eggert wrote:
> On 05/08/13 11:26, Anatol Pomozov wrote:
>> Why autoconf uses CPPFLAGS
>> (and not CPPFLAGS+CXXFLAGS) for headers discovery?
>
> It's a long story, but basically autoconf used to invoke
> just the preprocessor to test for header existence, partly
> on the gr
On 05/08/2013 09:19 PM, Allan McRae wrote:
> I believe autoconf uses "CPP CPPFLAGS" to detect headers mainly because
> of "-I" flags needing to be considered. Would an acceptable solution at
> the autoconf level be to split the CPPFLAGS into -I flags and others
> (-D, -U) and just use the -I ones
On 05/08/2013 08:19 PM, Allan McRae wrote:
> Would an acceptable solution at
> the autoconf level be to split the CPPFLAGS into -I flags and others
> (-D, -U) and just use the -I ones in the header test?
I don't think so, no. -D and -U can affect whether cpp works.
__
On 09/05/13 13:36, Eric Blake wrote:
> On 05/08/2013 09:19 PM, Allan McRae wrote:
>> I believe autoconf uses "CPP CPPFLAGS" to detect headers mainly because
>> of "-I" flags needing to be considered. Would an acceptable solution at
>> the autoconf level be to split the CPPFLAGS into -I flags and o
11 matches
Mail list logo