From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 13:14:23 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7336D37B401; Tue, 29 Jul 2003 13:14:23 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F0BE43FA3; Tue, 29 Jul 2003 13:14:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id GAA21015; Wed, 30 Jul 2003 06:14:18 +1000 Date: Wed, 30 Jul 2003 06:14:17 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ruslan Ermilov In-Reply-To: <20030729143848.GA37496@sunbay.com> Message-ID: <20030730060749.G978@gamplex.bde.org> References: <20030729103054.GA33488@BSDWins.Com> <20030729120105.GB20737@sunbay.com> <20030729125738.GA27879@sunbay.com> <20030729143848.GA37496@sunbay.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: Peter Wemm cc: John De Boskey Subject: Re: -current 'make release' status? [SOLVED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2003 20:14:23 -0000 On Tue, 29 Jul 2003, Ruslan Ermilov wrote: > ... > Forget what I've said about NO_WERROR, it (unfortunately) only > applies to the userland. > > Still, running "make rerelease KERNEL_FLAGS=WERROR=" gets the > release done. > > I wondered why I get it, and similarly my nigthly "buildkernel" > completed without errors. This turned out to be due to the > -O vs. -Os differences. For example, compiling vfs_subr.o > from the GENERIC kernel results in these same warnings when > compiled with COPTFLAGS="-Os -pipe". Peter, should we switch > -Werror back off in kern.pre.mk? Use -fno-strict-aliasing if you use -Os. Otherwise, -Os is stricter than -O. On second thoughts, -Os implies -f-strict-aliasing because -Os may need strict aliasing for the same reasons as -O2. We've seen -O2 in combination with broken aliasing in libm cause fatal errors. Better find part of -O2 that needs strict aliasing and turn it off too. Bruce