From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 16:54:07 2012 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 613751065670 for ; Fri, 6 Jul 2012 16:54:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ABF8D8FC0C for ; Fri, 6 Jul 2012 16:54:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA08246; Fri, 06 Jul 2012 19:54:03 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FF7182A.9070803@FreeBSD.org> Date: Fri, 06 Jul 2012 19:54:02 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120625 Thunderbird/13.0.1 MIME-Version: 1.0 To: Warner Losh References: <4FF60A9E.5070503@FreeBSD.org> <4FF6DB51.40904@FreeBSD.org> <508B8B4E-DF5E-412B-BD2B-86F21EBF4C8C@bsdimp.com> <4FF700CF.2000206@FreeBSD.org> <1DED79CC-CACD-4D22-9F1F-E3EB17938EB6@bsdimp.com> In-Reply-To: <1DED79CC-CACD-4D22-9F1F-E3EB17938EB6@bsdimp.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org Subject: Re: gcc46 header search path X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 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, 06 Jul 2012 16:54:07 -0000 on 06/07/2012 19:21 Warner Losh said the following: > I didn't, because I know the standard behavior. Turns out, I don't know > today's standard behavior, just the historical behavior of gcc, which has > changed over the life of FreeBSD. > > FreeBSD's standard compiler has never included it. There was talk about 10 > years ago about adding it, but it was shouted down as a stupid idea. I tend to > agree, but I can't articulate good reasons. Yeah. Honestly speaking I myself was not aware of what is written in that link and I thought that our gcc ports (from ports) added /usr/local/include to the default search path by some mistake. And if somebody asked me what I thought about the idea of adding /usr/local/include to the default path, I'd say that it was a stupid idea. But then I discovered that information. And verified that even Linux distributions that have zero files under /usr/local still keep the upstream behavior. So now I am thinking in opposite direction: do we have a strong enough reason to deviate from the default upstream behavior in this case. My main motivation is to keep behavior of base gcc and gcc-s from ports as close as possible (but no closer) to avoid such hidden gems when using the compilers interchangeably to build our ports tree. -- Andriy Gapon