[Removed bug-autoconf from the CC.] Martin Walch wrote:
> > When using rather new versions of glibc (2.8...) and gcc (4.3.3), I get an > > ugly warning on the screen during the execution of some configure scripts > > like > > the ones from coreutils or m4. > > ... > > As soon as basic optimization is turned on (-O1), the warning is thrown. In order to reproduce the problem, I also had to use ./configure CPPFLAGS=-D_FORTIFY_SOURCE=2 > > It says: > > > > *** %n in writable segment detected *** Confirmed. I see in the configure log: checking whether snprintf returns a byte count as in C99... yes checking whether snprintf fully supports the 'n' directive... *** %n in writable segment detected *** no This is fine: it explains why on this glibc system, the snprintf is not fully ISO C99 compliant. The aesthetics of the output are not perfect, but that also happens in a couple of other situations (such as when using AC_PROG_CC from autoconf 2.63 on MacOS X 10.5). > > and this is a warning that can not be suppressed by redirecting stdout or > > stderr as glibc opens a new tty. Confirmed. This is a problem with glibc. Why do they deem it best to ignore stderr and instead open a tty? Why don't they use syslog for this purpose? Definitely something that should be dealt with at glibc level. > > I think it is a bad idea to get this warning from a configure script. It > > does > > not appear in config.log but also can not be avoided. It confuses > > programmers > > and non-programmers. Yes, I agree with you. Error messages that bypass stderr are confusing. > > Also, it should be possible to ignore any warning within > > a configure script as it should be save to ignore any warning or error that > > shows up during a check. The problem, as you explained, is that glibc sets up its error output in a way that cannot be ignored or redirected. Please talk to http://sourceware.org/bugzilla/ . Bruno
