Re: fixing vs WARN_CFLAGS vs cross builds

Re: fixing vs WARN_CFLAGS vs cross builds

[Nathanael Nerode]

>Yes.  BUILD_CC is 3.2.3, and does not support these:
>
>cc1: unrecognized option `-Wno-variadic-macros'
>cc1: unrecognized option `-Wold-style-definition'
>
>> It may be reasonable to remove the WARN_CFLAGS setting in the fixinc.sh 
>> rule.  We don't use WARN_CFLAGS anyplace else where we use CC_FOR_BUILD. 
>>   This can work in stage2 etc builds, but this is probably not important 
>> enough to worry about.
>> 
>> It would be nice to have a proper bug report though.
>
>I was still trying to figure out what was supposed to happen from a
>theoretical standpoint.  
WARN_CFLAGS should be tested for compatibility with CC (which is basically
what happens on mainline ATM).

It should not be used with CC_FOR_BUILD, which could be different in any
compilation, since the user can specify it as a command-line option to 'make'.

>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.

-- 
Make sure your vote will count.
http://www.verifiedvoting.org/

Re: fixing vs WARN_CFLAGS vs cross builds

[Jim Wilson]

 > 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.

My last reply got messed up somehow.  Sorry.

Or maybe the recursive make command in the fixinc.sh rule should be 
setting WARN_CFLAGS to empty, because it is already included in 
BUILD_CFLAGS if it is supposed to be used?  I haven't checked to see 
which makes more sense.  I'm guessing that my first suggestion was the 
right one though.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: fixing vs WARN_CFLAGS vs cross builds

[Zack Weinberg]

Jim Wilson <wilson@specifixinc.com> writes:

>  > 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.
>
> My last reply got messed up somehow.  Sorry.
>
> Or maybe the recursive make command in the fixinc.sh rule should be
> setting WARN_CFLAGS to empty, because it is already included in
> BUILD_CFLAGS if it is supposed to be used?  I haven't checked to see
> which makes more sense.  I'm guessing that my first suggestion was the
> right one though.

It would be nice to be rid of the recursive make invocation here, but
that's too much work to ask for.

zw

fixing vs WARN_CFLAGS vs cross builds

[DJ Delorie]

I'm trying to cross-build a native DJGPP.  It tries to build fixinc,
but uses "gcc" as the compiler.  It passes a full WARN_CFLAGS, which
includes options that the system gcc doesn't understand, and so fails.

Should we just not pass WARN_CFLAGS when cross compiling that way?

Re: fixing vs WARN_CFLAGS vs cross builds

[Jim Wilson]

DJ Delorie wrote:
> I'm trying to cross-build a native DJGPP.  It tries to build fixinc,
> but uses "gcc" as the compiler.  It passes a full WARN_CFLAGS, which
> includes options that the system gcc doesn't understand, and so fails.
> Should we just not pass WARN_CFLAGS when cross compiling that way?

The gcc Makefile does not directly call "gcc" anywhere.  From a brief 
glance, I think you mean CC_FOR_BUILD, which you have set to gcc.

It isn't exactly clear why you have a problem though.  WARN_CFLAGS is 
set for a stage1 build only if the build (host?) compiler is gcc, and 
your compiler is gcc, so why is there a problem?  Is there a particular 
option which is the problem?  If so, which one?  Is this a versioning 
problem?  I.e. an option is in WARN_CFLAGS that is not supported by an 
old gcc version you are using for the bootstrap?  Or is the problem 
confusion between the host and build compiler, which may be different 
gcc versions?  Maybe we need a BUILD_WARN_CFLAGS separate from WARN_CFLAGS?

You haven't provided enough info here to see what the problem is.

It may be reasonable to remove the WARN_CFLAGS setting in the fixinc.sh 
rule.  We don't use WARN_CFLAGS anyplace else where we use CC_FOR_BUILD. 
  This can work in stage2 etc builds, but this is probably not important 
enough to worry about.

It would be nice to have a proper bug report though.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: fixing vs WARN_CFLAGS vs cross builds

[DJ Delorie]

> The gcc Makefile does not directly call "gcc" anywhere.  From a brief 
> glance, I think you mean CC_FOR_BUILD, which you have set to gcc.

Yes.

> It isn't exactly clear why you have a problem though.  WARN_CFLAGS is 
> set for a stage1 build only if the build (host?) compiler is gcc, and 
> your compiler is gcc, so why is there a problem?  Is there a particular 
> option which is the problem?  If so, which one?  Is this a versioning 
> problem?  I.e. an option is in WARN_CFLAGS that is not supported by an 
> old gcc version you are using for the bootstrap?

Yes.  BUILD_CC is 3.2.3, and does not support these:

cc1: unrecognized option `-Wno-variadic-macros'
cc1: unrecognized option `-Wold-style-definition'

> It may be reasonable to remove the WARN_CFLAGS setting in the fixinc.sh 
> rule.  We don't use WARN_CFLAGS anyplace else where we use CC_FOR_BUILD. 
>   This can work in stage2 etc builds, but this is probably not important 
> enough to worry about.
> 
> It would be nice to have a proper bug report though.

I was still trying to figure out what was supposed to happen from a
theoretical standpoint.  

I have a patch which tests for build!=host and disables WARN_CFLAGS,
but should fixinc *ever* be built with WARN_CFLAGS?

Re: fixing vs WARN_CFLAGS vs cross builds

[Jim Wilson]

On Tue, 2004-03-30 at 17:43, DJ Delorie wrote:
> Yes.  BUILD_CC is 3.2.3, and does not support these:
> cc1: unrecognized option `-Wno-variadic-macros'
> cc1: unrecognized option `-Wold-style-definition'

There is still an unanswered question here.  Why is this failing for
BUILD_CC but not CC or HOST_CC?  This needs further investigation.

I see that these options are in STRICT2_WARN which is not used except in
POSTSTAGE1_FLAGS_TO_PASS, which is only used for stage2 and stage3
builds.  Thus we only use the flags when we know that we are building
ourselves, in which case these options are always safe.

So I still don't see why you are having a problem.  You need to better
explain why your build is failing.  What exactly are you doing that is
causing the failure?

> I have a patch which tests for build!=host and disables WARN_CFLAGS,
> but should fixinc *ever* be built with WARN_CFLAGS?

We could in stage2 and stage3 builds, in which case we know that
CC_FOR_BUILD must be a compiler built from the current sources, as we
can only reach here for native builds.  That seems to be how it
currently works.

Are you perhaps trying to bootstrap a cross compiler somehow?  I don't
see how this can work, but this seems to be the only way to trigger this
failure.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: fixing vs WARN_CFLAGS vs cross builds

[DJ Delorie]

For background, I'm doing this:

	--build=i686-pc-linux-gnu
	--host=i586-pc-msdosdjgpp
	--target=i586-pc-msdosdjgpp

So, it's a native build, but cross-built.  DJGPP *does* use
fixincludes, so that should run.

Apparently, configure tests $CC for support of -Wno-long-long
-Wno-variadic-macros (and a few others) and adds them to the stage1
flags if supported.  However, $CC is a cross compiler, different
from $BUILD_CC.

"If the native compiler is GCC, we can enable warnings even in stage1."

Well, it is GCC, and strict1 propogates to WARN_CFLAGS, and
WARN_CFLAGS is passed to fixinc.  But the compiler used in fixinc is a
different gcc (BUILD_CC vs CC).

Re: fixing vs WARN_CFLAGS vs cross builds

[Jim Wilson]

On Tue, 2004-03-30 at 19:10, DJ Delorie wrote:
> Well, it is GCC, and strict1 propogates to WARN_CFLAGS, and
> WARN_CFLAGS is passed to fixinc.  But the compiler used in fixinc is a
> different gcc (BUILD_CC vs CC).

Thanks.  I see the problem now.  There is configure support that adds
options to strict1_warn based on CC.  I missed this when looking at the
code.  This was the info I was looking for.  These tests are obviously
unsafe when WARN_STRICT is used with CC_FOR_BUILD where CC_FOR_BUILD is
different from CC.

We would need a parallel set of tests and macros for a
BUILD_WARN_STRICT, and it seems unreasonable to ask you do that much
work to fix your cross compiler build problem.  So I think that simply
changing the fixinc.sh rule to not use WARN_STRICT is an acceptable
solution.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com