From: Jim Wilson <wilson@specifixinc.com>
To: DJ Delorie <dj@redhat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: fixing vs WARN_CFLAGS vs cross builds
Date: Wed, 31 Mar 2004 07:53:00 -0000 [thread overview]
Message-ID: <1080701413.1213.25.camel@leaf.tuliptree.org> (raw)
In-Reply-To: <200403310143.i2V1hFA0014438@greed.delorie.com>
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
next prev parent reply other threads:[~2004-03-31 2:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-30 0:29 DJ Delorie
2004-03-31 6:38 ` Jim Wilson
2004-03-31 6:40 ` DJ Delorie
2004-03-31 7:53 ` Jim Wilson [this message]
2004-03-31 7:55 ` DJ Delorie
2004-03-31 8:09 ` Jim Wilson
2004-03-31 8:03 Nathanael Nerode
2004-03-31 10:52 ` Jim Wilson
2004-03-31 12:43 ` Zack Weinberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1080701413.1213.25.camel@leaf.tuliptree.org \
--to=wilson@specifixinc.com \
--cc=dj@redhat.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).