From owner-freebsd-toolchain@freebsd.org Fri Apr 1 14:25:25 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 A9CE6AEB4A8 for ; Fri, 1 Apr 2016 14:25:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 76C4B1951 for ; Fri, 1 Apr 2016 14:25:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id q128so150868001iof.3 for ; Fri, 01 Apr 2016 07:25:25 -0700 (PDT) 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; bh=ztcpeWmxeXvDy1B2jwK/EMrAtztvPo6Dy8umTYIOtVI=; b=QiLU4d7K8buq1pwv9QhnKxh4t2VcTQy03nRuMlALFJiOA9Dc76rQLvXq2bC8Ku6EXV wOZqq/h0Z3enPngJzAAto/1apd5QyyZ2LXPgqATkgqYLf08K3NDsWqCUB0Pm4/rYLoGW ibvyYJKxHe/2GqtD0YSCfr90YfkRCaoIfFcm72tcp9OTbLs1zd8Q4C2x6oMl7eRM8D8o F6zja00NxnFzFHyL5auyBEIv4eJWlACf96pgMWgWaR7ytHG3B8HgDWZmoV9PtKncsxnt GeyKpdi42/acl6YFmxbw2Lc9kyDgK118olRMzsBPfyK+DLrtLL9ICWsiVBYLq/B5t7iD ewDA== 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; bh=ztcpeWmxeXvDy1B2jwK/EMrAtztvPo6Dy8umTYIOtVI=; b=INqx8SPwPlz8aTdd7pw38QCdS1toGQ39x12w2sSLo1TDmL8hRyJ8CqXNnCYDgiwXbC sCmA0XBKD2uiQlgf6t8axL2aVZEvOMyvuexLP8H509w1eORfdEymR67D+3tijhQm4FE5 lduTV4t32VnwVPziq++SEzsALwedhHCFSJbit9EMFNjXPXzdtoLokHZXziBgVGoXwg4P MVFcATVz8BYfozRXhQ/SRs937aIzYvGCePfhda3HUy3dHXYEasoQN8G/WYo1ypeTd0vP zRmYxKXXrNuimyQOPi9phCOAmVx405lDfYE3GxEMq9e/v9JbEXz52HGf/Ys5RDzz62k6 DWPg== X-Gm-Message-State: AD7BkJL5JHAe0uOomaVqzyw6TVPaAj7J6jbLaYELQtzquh7v/2aL8fdjIgYMtbuVgfYTCKgCmOlvH/kjtlumgw== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr4703129ioe.135.1459520724863; Fri, 01 Apr 2016 07:25:24 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.194.3 with HTTP; Fri, 1 Apr 2016 07:25:24 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> Date: Fri, 1 Apr 2016 08:25:24 -0600 X-Google-Sender-Auth: 4dKbIK7UyA631kxSL2aolgvrY_A Message-ID: Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Warner Losh To: Dimitry Andric Cc: Bryan Drewery , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML , Mark Millard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 14:25:25 -0000 On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric wrote: > On 01 Apr 2016, at 00:44, Warner Losh wrote: > > > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery > wrote: > >> I didn't realize the ports compiler was defaulting /usr/local/include > >> into the search path now. It does not have /usr/local/lib in the > >> default library path as far as I can tell. It's also broken for its > >> -rpath (noted in its pkg-message). So having a default > >> /usr/local/include path seems odd. > > > > It has for a while now. It=E2=80=99s one of the maddening inconsistenci= es that > abound in this > > area. I took a poll a while ago and there seemed to be widespread > support for adding > > it to the base compiler. > > This was the main reason /usr/local/include was *not* included in the > base compiler, otherwise it would unpredictably pick up headers in > /usr/local/include during builds. You can never know which conflicting > headers a certain user has installed in /usr/local/include... :) That's why it shouldn't be *FIRST*, not why it shouldn't be there at all. >> Adding -isystem /usr/include to fix this is probably possible but > >> there's a risk someone will remove it as redundant. In this case I wi= sh > >> /usr/include was first but I'm not sure what impact that would have on > >> consumers expecting /usr/local/include (and /usr/local/lib) overrides = to > >> work, though they would need to pass a -L /usr/local/lib anyhow and > >> would likely be passing -I /usr/local/lib too. > > > > /usr/include should be first. But it isn=E2=80=99t. That=E2=80=99s anot= her inconsistency > that was found > > when we looked at /usr/local stuff. Someone recently added > /usr/local/bin to the path, > > if I recall correctly. > > Isn't that a bit of a bikeshed? I guess some people would just as well > prefer /usr/local/include to be first, just like some people prefer > /usr/local/bin before /usr/bin in their PATH. > Sigh. No. /usr/local is moving into many different things in the base and ports. We should do it in a consistent way. What we have now is not consistent and somewhat brittle. > In any case, if such paths are added to external compilers, we better > make sure almost everything in buildworld uses -nostdinc, and specifying > exactly the include directories we need, and no others. Cumbersome, but > maybe for a good cause. That's the non-brittle solution here. An over-reliance on defaults makes it difficult to ensure other compilers will work, especially ones we don't tightly control the defaults for. Warner