/me <- stoopid.

# On Thu, 10 Jan 2002, Greywolf wrote:
#
# : # On Thu, 10 Jan 2002, Greywolf wrote:
# : #
# : # : Greetings.  Working with a current source tree freshly cvs updated.
# : #
# : # `Please post the contents of your mk.conf, and the command you are using to
# : # build, if you are having a build problem.'
# :
# : Certainly.  I am NOT setting all that stuff; it's coming from the
# : bsd.*.mk files.   I'm only setting -O3 -pipe.
#
# `Please post the contents of your mk.conf, and the command you are using to
# build, if you are having a build problem.'

'I attached it instead, is this going to be a problem?'

# Obviously *something* is setting it, and thus I need to know *precisely* how
# you're building.

This is where the stoopid [tm] part comes in.

- from mk.conf -

.ifndef DEBUGFLAGS
CFLAGS+=        -O3 -pipe
.else
CFLAGS+=        -O -pipe ${DEBUGFLAGS}
.endif

HOST_CFLAGS+=   ${CFLAGS}

- end excerpt -

I changed CFLAGS above to LOCAL_CFLAGS, and that fixed the problem.

# : Then I would posit that, unless you have specified otherwise, the tools
# : system will never be better than half-baked.
#
# -Wall -Werror assumes a lot about the build scheme in use (and
# -Wstrict-prototypes even more so).  The GNU tools are not likely to pass all
# these checks on all host platforms anytime soon, as the GNU maintainers
# don't watch the gcc messages as closely as we do.  Hence, the GNU tools
# aren't built with WARNS set.
#
# As to mkdep, as I said, I'll be fixing that in just a moment.

'k.  Thanks for the brick -- it helped a lot.

# -- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
# -- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/

				--*greywolf;
--
NetBSD: "Progress on your system is closer than it appears."