From owner-freebsd-current@FreeBSD.ORG Tue Jul 29 03:33:32 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 50C2137B401 for ; Tue, 29 Jul 2003 03:33:32 -0700 (PDT) Received: from bsdone.bsdwins.com (www.bsdwins.com [192.58.184.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E42B43FB1 for ; Tue, 29 Jul 2003 03:33:31 -0700 (PDT) (envelope-from jwd@bsdwins.com) Received: from bsdone.bsdwins.com (localhost [127.0.0.1]) by bsdone.bsdwins.com (8.12.9/8.12.9) with ESMTP id h6TAUsVr005626 for ; Tue, 29 Jul 2003 06:30:54 -0400 (EDT) (envelope-from jwd@www.bsdwins.com) Received: (from jwd@localhost) by bsdone.bsdwins.com (8.12.9/8.12.9/Submit) id h6TAUsAU005625 for freebsd-current@freebsd.org; Tue, 29 Jul 2003 06:30:54 -0400 (EDT) Date: Tue, 29 Jul 2003 06:30:54 -0400 From: John To: Current List Message-ID: <20030729103054.GA33488@BSDWins.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: -current 'make release' status? 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 10:33:32 -0000 Hi, I'm currently down to this patch to allow a make release to complete for -current: =================================================================== RCS file: /home/ncvs/src/release/Makefile,v retrieving revision 1.801 diff -u -r1.801 Makefile --- Makefile 26 Jul 2003 06:47:40 -0000 1.801 +++ Makefile 29 Jul 2003 05:09:31 -0000 @@ -1053,7 +1053,7 @@ cd ${.CURDIR}/..; \ KERNEL_KO=BOOTMFS KODIR= \ ${CROSSMAKE} ${KERNEL_FLAGS} -DNO_MODULES -DNO_KERNELCLEAN \ - KERNCONF=BOOTMFS COPTFLAGS="-Os -pipe" -DNO_CPU_COPTFLAGS \ + KERNCONF=BOOTMFS COPTFLAGS="-Os -pipe -w" -DNO_CPU_COPTFLAGS \ buildkernel reinstallkernel \ DESTDIR=${RD}/kernels [ -r ${.CURDIR}/../sys/${TARGET}/conf/BOOTMFS.hints ] && \ without it, the following causes BOOTMFS to abort: cc -c -Os -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src /sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/a th/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mno-align-long-strings -mpreferred-st ack-boundary=2 -ffreestanding -Werror /usr/src/sys/cam/cam_periph.c In file included from /usr/src/sys/cam/cam_periph.c:41: /usr/src/sys/sys/buf.h: In function `BUF_LOCK': /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h:289: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h: In function `BUF_TIMELOCK': /usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h:310: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h: In function `BUF_UNLOCK': /usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h:325: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h: In function `BUF_KERNPROC': /usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h:350: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/sys/buf.h:352: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/cam/cam_periph.c: In function `cam_periph_mapmem': /usr/src/sys/cam/cam_periph.c:624: warning: dereferencing type-punned pointer will break strict-aliasing rules . . . Thoughts? Plans? It's also worth noting that the BOOTMFS kernel build is inconsistant. The initial build via 'make release' fails with no patch. After the failure, a followup: chroot $RDIR /bin/sh /mk doMFSKERN works correctly. The 'make release' environment is setup differently from that of /mk. Depending on what folks think, maybe some form of: make mk TARGET=doMFSKERN would be appropriate to guarentee consistancy. Just a thought. -John