Control: forwarded -1 http://lists.gnu.org/archive/html/bug-autoconf/2014-01/msg00003.html
On 2014-01-08 21:55:56 -0800, Ben Pfaff wrote: > On Wed, Jan 08, 2014 at 09:44:20AM +0100, Vincent Lefevre wrote: > > On 2014-01-07 21:30:29 -0800, Ben Pfaff wrote: > > > On Fri, Jan 03, 2014 at 10:22:27PM +0100, Vincent Lefevre wrote: > > > > A developer may want to test his software with > > > > -Werror=old-style-definition (in particular because such definitions > > > > could be a real bug in the software). But configure fails because > > > > autoconf generates such a function definition. For instance: > > > > > > In my opinion, it's a mistake to run "configure" tests with -Werror. > > > > I don't see why. > > As compilers evolve, they will inevitably come to issue new warnings, > some of which will be triggered by configure tests. Authors of Autoconf > tests cannot possibly write them to avoid all warnings issued by future > versions of GCC. I agree, but in the current case, the change is not required due to a warning from GCC, but because of an obsolescent feature of C (but both are related: the goal of the warning here is to signal the use of an obsolescent feature of C). > > > I suggest adding such flags after configure tests have been run, as > > > with the --enable-Werror configure flag supported by Open vSwitch: > > > > > > dnl OVS_ENABLE_WERROR > > > AC_DEFUN([OVS_ENABLE_WERROR], > > > [AC_ARG_ENABLE( > > > [Werror], > > > [AC_HELP_STRING([--enable-Werror], [Add -Werror to CFLAGS])], > > > [], [enable_Werror=no]) > > > AC_CONFIG_COMMANDS_PRE( > > > [if test "X$enable_Werror" = Xyes; then > > > CFLAGS="$CFLAGS -Werror" > > > fi])]) > > > > This doesn't solve the problem at all: whether -Werror is used via > > --enable-Werror or via > > > > ./configure ... CFLAGS="... -Werror" > > > > the same errors will occur. > > No, configuration time errors will not occur with this macro, because > this macro adds -Werror only after all of the configuration tests have > already run. Some configure tests *must* be done with the same options as the compilation, so that some features in the program or the tests can be disabled (via the preprocessor) if they are not supported due to the use of -Werror. > > > I guess that -Werror=old-style-definition is somewhat more restricted, > > > but a similar solution can be used. > > > > Actually I wasn't using -Werror=old-style-definition directly, but > > > > ./configure CFLAGS="-Wall -Wold-style-declaration -Wold-style-definition > > -Wmissing-parameter-type -Wmissing-prototypes -Wmissing-declarations > > -Wmissing-field-initializers -Werror" > > If you did the same thing but dropped -Werror from CFLAGS and added > --enable-Werror, there would be no problem with configuration tests. But the build (of the software or the tests) could fail due to a feature that should have been disabled by an error detected with -Werror at configure time. > > My proposed patch concerning autoconf: > > > > http://lists.gnu.org/archive/html/autoconf-patches/2014-01/msg00003.html > > You reported this upstream? I'm not sure why you're reporting it to > Debian also, then. I first reported the problem in Debian since Debian's autoconf version is older than upstream's dev version (BTW, it seems that I've just found another problem related to MPFR's Static Assertion test, which is triggered with Debian's autoconf package, but not upstream) and upstream doesn't have a BTS, AFAIK. Then I reported it upstream. Now, I thought I also added the forwarded URL's to Debian's bug report, but I forgot (GNU's mailing-list system is poorly designed: one has to wait for the URL, so that it is easy to forget...). This is now done with this message. Upstream told be to wrote a patch, which I did, hence the URL just above. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
