From owner-freebsd-ppc@freebsd.org Sun Feb 14 23:40:59 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75B03AA905F for ; Sun, 14 Feb 2016 23:40:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B5D6CD8 for ; Sun, 14 Feb 2016 23:40:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32235 invoked from network); 14 Feb 2016 23:41:12 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 23:41:12 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 14 Feb 2016 18:41:00 -0500 (EST) Received: (qmail 4198 invoked from network); 14 Feb 2016 23:41:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 14 Feb 2016 23:41:00 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 755791C43E3; Sun, 14 Feb 2016 15:40:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts? From: Mark Millard In-Reply-To: <85E263E8-445F-4AA0-82E7-4CDBC28509B7@dsl-only.net> Date: Sun, 14 Feb 2016 15:40:56 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <338854A3-DB47-4356-B63C-1901894FA1D2@dsl-only.net> References: <85E263E8-445F-4AA0-82E7-4CDBC28509B7@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 23:40:59 -0000 A top post as I figured out what is going on: My original src.conf had a bad "optimization" where I had been thinking = that since I had a working compiler that was not being updated with new = source code that I could avoid the time to rebuild it during the = bootstrap: WITHOUT_GCC_BOOTSTRAP=3D But this makes the default include/library paths wrong for buildworld = and the like and so requires them to be enforced on the command line. = The build environment is not set up to automatically do that in such = cases. So I had wondered out of bounds. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-14, at 12:35 PM, Mark Millard wrote: >=20 > On 2016-Feb-14, at 12:16 PM, Warner Losh wrote: >>=20 >> On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard = wrote: >> Is buildworld supposed to use /usr/include's area for finding files = by default? (I'm not talking of ${WORLDTMP}/usr/include but of just = /usr/include.) >>=20 >> Yes, but only though the end of the bootstrap phase. >>=20 >> It does use /usr/include's area for some contexts: self-hosted builds = without a special XCC full path (e.g., an implicit TARGET_ARCH=3Dpowerpc = on a powerpc host using gcc 4.2.1 without an explicit XCC assignment = that also directs it to gcc 4.2.1 via a full path). >>=20 >> /usr/src/Makefile.inc1 has the following sort of logic: >>=20 >>> .if ${XCC:N${CCACHE_BIN}:M/*} >> . . . >>> .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc >>> XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib >>> XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ >> . . . >>> .else >> . . . >>> .endif >>> XCFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} >>> XCXXFLAGS+=3D --sysroot=3D${WORLDTMP} ${BFLAGS} >>> .else >>> .if defined(CROSS_BINUTILS_PREFIX) && = exists(${CROSS_BINUTILS_PREFIX}) >>> BFLAGS+=3D -B${CROSS_BINUTILS_PREFIX} >>> XCFLAGS+=3D ${BFLAGS} >>> XCXXFLAGS+=3D ${BFLAGS} >>> .endif >>> .endif # ${XCC:M/*} >>=20 >> For contexts without the -isystem and/or --sysroot in XCFLAGS . . . >>=20 >> Is it appropriate to submit bug reports for buildworld getting = include files from /usr/include instead of from ${WORLDTMP} or from = /usr/src areas? >>=20 >> If it is during the build everything phase, yes it is a build bug. If = it is during the bootstrap phase, then yes, it is expected we use the = host, but there's some incompatibility in bootstrapping we need to fix. >>=20 >> This tends to be noticed when something like the following. . . >>=20 >>> # svnlite update -r295453 /usr/src >>> # env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc-gcc421.powerpc-host = MAKEOBJDIRPREFIX=3D/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld = buildkernel >>=20 >> ends up with compile errors from using some older /usr/include header = files that are no longer sufficient to allow compilation. >>=20 >> I recently had a couple of examples where the cc command in the = script output file for the failing compiles showed no -I , no -isystem , = no --sysroot , nothing that would have allowed it to even potentially = avoid /usr/include (old file) use. The Makefile*'s involved had no = CFLAGS+=3DSOMETHING_DIRECTING_INCLUDE_SEARCH . >>=20 >> (Some types of header changes might not stop a build but might make = the build result wrong without much explicit notification. I'd prefer to = avoid such as well.) >>=20 >> I expect that there are analogous points/questions for finding = libraries. >>=20 >> Specific examples would be most welcome. >>=20 >> Warner=20 >=20 > I had submitted the following bug reports for the two recent examples = that prompted my question. . . >=20 >=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207147 for: >=20 > In file included from /usr/src/lib/libmemstat/memstat_uma.c:37: > /usr/include/vm/uma_int.h:310: error: field 'uz_maxaction' has = incomplete type >=20 >=20 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207148 for: >=20 > /usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use = in this function) >=20 >=20 >=20 > In both cases the /usr/include vintage file was in use after my update = of /usr/src to -r295453. In both cases the "cc" command had no -I , no = -sysroot , and no -isystem to direct the searching for the header file. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20