----- Original Message ----- From: "Bruno Haible" <br...@clisp.org> To: "Paolo Bonzini" <bonz...@gnu.org> Cc: "Jim Meyering" <j...@meyering.net>; "Gilles Espinasse" <g....@free.fr>; <5999-d...@debbugs.gnu.org>; <bug-gnulib@gnu.org> Sent: Tuesday, April 27, 2010 1:27 AM Subject: Re: bug#5999: new snapshot available: coreutils-8.4.100-81926
> Paolo Bonzini wrote: > > > Here's a patch to make that diagnostic go where it belongs > > > for all gnulib-using projects: > > > > I wonder if we shouldn't do that for all _autoconf_-using projects! > > Or, at least, for all tests in all gnulib-using projects. There are > more possible causes of a FORTIFY message, according to > <https://wiki.edubuntu.org/CompilerFlags> > > How about this proposed patch? > > > 2010-04-26 Jim Meyering <j...@meyering.net> > Bruno Haible <br...@clisp.org> > > * m4/gnulib-common.m4 (gl_COMMON_BODY): Set LIBC_FATAL_STDERR_. > > --- m4/gnulib-common.m4.orig Tue Apr 27 01:25:33 2010 > +++ m4/gnulib-common.m4 Tue Apr 27 00:01:03 2010 > @@ -1,4 +1,4 @@ > -# gnulib-common.m4 serial 19 > +# gnulib-common.m4 serial 20 > dnl Copyright (C) 2007-2010 Free Software Foundation, Inc. > dnl This file is free software; the Free Software Foundation > dnl gives unlimited permission to copy and/or distribute it, > @@ -35,6 +35,12 @@ > is a misnomer outside of parameter lists. */ > #define _UNUSED_PARAMETER_ _GL_UNUSED > ]) > + dnl Preparation for running test programs: > + dnl Tell glibc to write diagnostics from -D_FORTIFY_SOURCE=2 to stderr, not > + dnl to /dev/tty, so that can be redirected to log files. Such diagnostics > + dnl occur e.g. in the macros gl_PRINTF_DIRECTIVE_N, gl_SNPRINTF_DIRECTIVE_N. > + LIBC_FATAL_STDERR_=1 > + export LIBC_FATAL_STDERR_ > ]) > > # gl_MODULE_INDICATOR_CONDITION I understand there is a problem but I am unsure of the direction to go. I made this stupid patch (attached) that include the same test than gl_cv_func_printf_directive_n in coreutils sleep usage [chroot-i486] root:/usr/src/coreutils-8.5$ gl_cv_func_printf_directive_n=no ./configure --prefix=/usr [chroot-i486] root:/usr/src/coreutils-8.5$ make [chroot-i486] root:/usr/src/coreutils-8.5$ ./src/sleep; echo $? ./src/sleep: missing operand Try `./src/sleep --help' for more information. *** %n in writable segment detected *** Aborted 134 [chroot-i486] root:/usr/src/coreutils-8.5$ make clean [chroot-i486] root:/usr/src/coreutils-8.5$ gl_cv_func_printf_directive_n=yes ./configure --prefix=/usr [chroot-i486] root:/usr/src/coreutils-8.5$ make [chroot-i486] root:/usr/src/coreutils-8.5$ ./src/sleep; echo $? ./src/sleep: missing operand Try `./src/sleep --help' for more information. *** %n in writable segment detected *** Aborted 134 So result is the same with gl_cv_func_printf_directive_n=no or gl_cv_func_printf_directive_n=yes. Am I wrong somewhere? What is the gain that this test is so written? Gilles
sleep_writable-format.patch
Description: Binary data
