Re: No Subject

[Jim Wilson <wilson at specifixinc dot com>]

On Tue, 2004-03-30 at 20:41, Nathanael Nerode wrote:
> >I have a patch which tests for build!=host and disables WARN_CFLAGS,
> >but should fixinc *ever* be built with WARN_CFLAGS?
> No, it shouldn't.

I think this is an over simplistic answer.  You really should be looking
more closely at this issue if you want to comment on it.

With a native configure, BUILD_CFLAGS includes ALL_CFLAGS which includes
WARN_CFLAGS which includes GCC_WARN_CFLAGS which includes STRICT_WARN
and maybe also STRICT2_WARN.  So clearly, the warning flags are used
when building fixinc in some cases, and that should not be broken.

The real problem here seems to be much more subtle and complex, and it
has something to do with how the recursive make for the fixinc.sh rule
works, and how we set these variables when CC_FOR_BUILD != CC.  I
haven't tried doing a build, so I don't know what all is happening here.

In fact, looking at my log from a native build, I see that the warning
flags occur twice, e.g. -Wall appears twice on the gcc command line. 
The command lines for the generator files do not have this problem.  So
there is something funny going on here that I don't fully understand.

Oh, I see the problem.  The recursive make command sets CFLAGS to
include BUILD_CFLAGS.  Then the recursive make itself uses ALL_CFLAGS
which includes CFLAGS and WARN_CFLAGS, and thus the warning flags are
used twice.  More importantly, this causes us to use WARN_CFLAGS with
CC_FOR_BUILD when it shouldn't be.  I think this is the actual
underlying problem.  The recursive make command in the fixinc.sh rule
should perhaps be setting ALL_CFLAGS instead of CFLAGS because the
default .c.o rule uses ALL_CFLAGS.  I think this would solve DJ's
problem, and would eliminate the duplicate flags in the native case
too.  We would also have to fix the export rule to export ALL_CFLAGS
instead of CFLAGS.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com