On 09/23/2013 11:30 AM, Eric Blake wrote: > Hello Dago, > > On 09/23/2013 09:07 AM, Dagobert Michelsen wrote: >> Hi Erik, > > It's Eric, but you're not the first to make that mistake :) > >>> I don't observe this behavior on my host (Sun Studio 12.3, >>> Solaris 10 sparc). I get the bad behavior only if I run >>> 'configure' with the --enable-gcc-warnings option, and >>> a simple workaround is to not use that option. >> >> I didn't enable gcc-warnings, but as it turns out this flag is automatically >> enabled when $srcdir/.git is present: > > Then as a workaround, use './configure --disable-gcc-warnings' until we > fix the issue upstream. > >> >> However, when I browse git the automatic detection of .git is not in there: >> >> http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=configure.ac;h=2fe6d9e8189d4083b58ba10bfbbe558da15f393b;hb=c09a187c50f2f74e89d4d0991bdbd2c6846cc707 > > You're browsing the wrong branch. It IS present on branch-1.4, which is > the source we used for cutting 1.4.17. > > http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=configure.ac;h=2defd94f;hb=f58fbbd8 > >> By coincidence we use git to apply patches in our build system >> to upstream sources if necessary, so this is the thing that >> confuses the build. > > Makes sense; it's hard to tell whether you are in a git repository for > upstream development vs. a git repository that applies patches to a > released tarball. Maybe we can make the default be even smarter by > recognizing a tarball-only file (ie. if .tarball-version exists, do NOT > blindly enable gcc warnings) - but that will still only mask the problem > of upstream gnulib's warning module getting the wrong answer for the Sun > compiler. > >> When I disable using git in our buildsystem >> the compilation works fine. I would prefer a system that enabled flags >> explicitly and not by inspecting side effects but I can understand the >> current behaviour. > > Yes, I'll patch m4 to use .tarball-version rather than just .git as the > witness for whether a development build is being attempted; but there's > still the matter of teaching gnulib's warning module how to recognize > that '-fdiagnostics-show-option' and '-funit-at-a-time' are NOT valid > warning flags for your compiler. Does your compiler include any flag > that forces the compiler to reject unknown warning parameters with > non-zero exit status, instead of merely warning that they are being > ignored until link phase? > > Paul, since you seem to have easy access to the same compiler, is this > something where you can tackle the gnulib patch faster than I can? >
I hope I will be forgiven for quoting everything. Eric Blake wrote in part: << use './configure --disable-gcc-warnings' until <snip> >>. It seems that GNU M4 is required before building GNU Autoconf, and that Autoconf is used in creating "configure" shell scripts ... Ref. to GNU Autoconf homepage: http://www.gnu.org/software/autoconf/ Can Autoconf by given options? Or, what tells Autoconf how to write a configure script, and where are the configure options set/defined? In particular, the "--disable-gcc-warnings" option or flag? Finally, what precedes in the Build Tool-chain "GNU M4"? regards, David Bernier
