Dear Eric, Thank you for your quick response.
On 2017/01/28 0:00, Eric Blake wrote:
On 01/27/2017 05:31 AM, ishik...@yk.rim.or.jp wrote:In configure script generated by autoconf 2.13 for mozilla software # Generated automatically using autoconf version 2.13 # Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.Wow that's old. Can you convince the project to upgrade their configure.in file to use autoconf 2.69 instead?
I realize that I do have both autconf213 and autoconf (2.69) on MY linux PC (Debian GNU/Linux).
Not sure, though. how the Mozilla developers would update the manner to create configure from configure.in. It seems that they have abandoned the route and try moving into their own configuration tool written in python. In the meantime, the old configure is left as old-configure and is executed and old-configure.in has, near the beginning, the following lines:
dnl Process this file with autoconf to produce a configure script.
dnl ========================================================
AC_PREREQ(2.13) <==== !?
AC_INIT(config/config.mk)
AC_CONFIG_AUX_DIR(${srcdir}/build/autoconf)
AC_CANONICAL_SYSTEM
Does AC_PRERQ(2.13) require the use of autoconf213?
Or can we use autoconf (2.69) safely? If we can use later versions
safely, I would certainly suggest upgrading to mozilla's mailing list.
I found a few tests that failed if -Werror=unsed-variable is defined for CFLAGS (an environment variable).
After sending out my report, I thought about it and I agree that -Werror=... would be nightmarish to deal with as you mention near the beginning of next paragraph:
Generally, ANY use of -Werror during configure is going to cause problems. Our general advice is "don't do that". If you want to test if a particular warning flag is supported, do so (and in fact, there's patches posted that I still want to incorporate into autoconf 2.70 that make warning flag probing easier) - but only for the duration of that test. Don't actually change CFLAGS for the rest of the configure suite. GNU Coreutils is a good example of how to probe for -Werror and even use it via a separate Makefile.am variable, without having it on to mess with the rest of the configure probes.
What is puzzling me right now is that I have two Debian GNU/Linux with very similar configuration and on one machine I get the problem which I reported, but on the other machine somehow I do NOT get the problem. Very confusing...(Not only that on the other machine, as of today, I noticed a GCC 6 crash (dreaded internal compiler error), but not on this machine where I am writing this e-mail.
I am driven nuts...There may be a subtle configuration difference somewhere [this machine I use fetches more ambitious testing packages while the other PC is in an office setting and use more stable package repository], but
this kind of subtle issue may be exactly why we should avoid using -Werror during configure. If I have time I would love to check how GNU Coreutils handles this issue.The reason I had to add "-Werror=unused-variable" to my CFLAGS environment variable is that Mozilla's compilation farm available to developers seems to apply this -Werror setting per directory basis, and in order to detect such warning-turned-into-error locally on my home/office PC [I found a few compilation errors ONLY AFTER I submit my source patches to mozilla's compilation farm. The source compiled fine on my PCs.], I had to add this -Werror, but I was not sure how to apply the option per directory-basis in the framework mozilla uses to build firefox browser and thunderbird mail client.
Right now, I apply the CFLAGS setting for the whole source tree.Their command to build is very complex and handles the configure and build in one command and it is not easy to separate the two.
Thank you again for your feedback. Best Regards, Chiaki Ishikawa
