From owner-freebsd-toolchain@freebsd.org Sun Feb 14 20:17:00 2016 Return-Path: Delivered-To: freebsd-toolchain@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 1C52DAA8770 for ; Sun, 14 Feb 2016 20:17:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAA0717FA for ; Sun, 14 Feb 2016 20:16:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x236.google.com with SMTP id y9so99138327qgd.3 for ; Sun, 14 Feb 2016 12:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=yZgkoqeM5FhkF+24Q1MVUmBllSsqAKGEKbIXsFNy5hg=; b=nXUJA4oAP5u6IMgJkQFVb9wgL/CZATgWo8V2imd/mJFCyyXmQP1aKCgytIKb4LGQz0 o5zjOJ/EhO0z9P6iqN13k99xyPNuv1CM6Tjkq3Fbj+RufZ2ADS8WLKThiD46Lrb3/Z2F JQlmsJKpkKJUalO5jmFJILyFyzhJfgjWdqdlGpiECqnrywYzTvxFAtaJ57rYZpVqTmuZ hybpXVxbu1K4XaJwOzKUmeGdUY/8wMR9sGygbKJkE3dLi0zKl0lwcoP36UqiYLV5wRZP NtYsuvSNRayJlyZtznparWtRXGOhxhxskxgRV7T99r3o8tAy09Wy0RxwjukmIM36TKIb j9RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yZgkoqeM5FhkF+24Q1MVUmBllSsqAKGEKbIXsFNy5hg=; b=loqst4vMRiCDkemI2PRws/GOacPgYHvmIwQQxWScPFVYezbtGoqkOrmkg3KsPrkFtN tzV47vgKVD0OGUY7fzef61x5RL0E03RZP4bJTXbRih++i5BqtzBf1x09krD0WE3nT3gE tSpcJSHkADxpTDP/T2Nr6IGGKViIj9RJ2eBGM+UxF+GJXYxAx0jtwUjpEjCh5OXXlOvg xmnyHSrG76qYnIINuPDKsUtSe9DhShk0qTaHObvOo2GDe7ocCzjUoX8jVvizq6+GF2gx tbKSjexCjCUcwesi72r2SHbvFdOcLXTmO0WMxCPj+6nPxxNFMeIJ0iSfEhrqWZGcBnT/ IxBQ== X-Gm-Message-State: AG10YOSDlWu/BiBpurX5OePMRNUKt0l8E8wEsy1/aSYmX9Z4nBmXU2/27CXYAokQIOIKkwxFgRd/o6sBhOVmyA== MIME-Version: 1.0 X-Received: by 10.140.28.162 with SMTP id 31mr16270187qgz.81.1455481018888; Sun, 14 Feb 2016 12:16:58 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Sun, 14 Feb 2016 12:16:58 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Sun, 14 Feb 2016 13:16:58 -0700 X-Google-Sender-Auth: UkHE7PnABmt5GPVHTPa7XdYbTic Message-ID: Subject: Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts? From: Warner Losh To: Mark Millard Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Feb 2016 20:17:00 -0000 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.) > Yes, but only though the end of the bootstrap phase. > 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=powerpc 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). > > /usr/src/Makefile.inc1 has the following sort of logic: > > > .if ${XCC:N${CCACHE_BIN}:M/*} > . . . > > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc > > XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib > > XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11 > -L${WORLDTMP}/../lib/libc++ > . . . > > .else > . . . > > .endif > > XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > > XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} > > .else > > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX}) > > BFLAGS+= -B${CROSS_BINUTILS_PREFIX} > > XCFLAGS+= ${BFLAGS} > > XCXXFLAGS+= ${BFLAGS} > > .endif > > .endif # ${XCC:M/*} > > For contexts without the -isystem and/or --sysroot in XCFLAGS . . . > > Is it appropriate to submit bug reports for buildworld getting include > files from /usr/include instead of from ${WORLDTMP} or from /usr/src areas? > 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. > This tends to be noticed when something like the following. . . > > > # svnlite update -r295453 /usr/src > > # env __MAKE_CONF=/root/src.configs/make.conf > SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host > MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld > buildkernel > > ends up with compile errors from using some older /usr/include header > files that are no longer sufficient to allow compilation. > > 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+=SOMETHING_DIRECTING_INCLUDE_SEARCH . > > (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.) > > I expect that there are analogous points/questions for finding libraries. > Specific examples would be most welcome. Warner