From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 12:34:30 2012 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC9CA106564A for ; Fri, 6 Jul 2012 12:34:30 +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 38EB48FC0C for ; Fri, 6 Jul 2012 12:34:26 +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 PAA06672 for ; Fri, 06 Jul 2012 15:34:25 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FF6DB51.40904@FreeBSD.org> Date: Fri, 06 Jul 2012 15:34:25 +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: toolchain@FreeBSD.org References: <4FF60A9E.5070503@FreeBSD.org> In-Reply-To: <4FF60A9E.5070503@FreeBSD.org> X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: <4FF60A9E.5070503@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Fwd: 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 12:34:30 -0000 Inviting wider audience to the discussion. -------- Original Message -------- Date: Fri, 06 Jul 2012 00:43:58 +0300 From: Andriy Gapon Subject: Re: gcc46 header search path on 05/07/2012 17:15 Andriy Gapon said the following: > > Gerald, > > while thinking what to reply in our other conversation I ran into another issue > with gcc46: > > $ echo "" | cpp46 -v > [trim] > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd10.0/4.6.3/include > /usr/local/include > /usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd10.0/4.6.3/include-fixed > /usr/include > End of search list. > [trim] > > I don't think that /usr/local/include should automagically appear in the search > list. Base gcc doesn't have it and there doesn't seem to be a good reason to > include "arbitrary" non-system directory into the default search path. > On the other hand the above seems to match the default upstream behavior as described here: http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html It's understandable that such a difference between the base gcc compiler and gcc compilers from ports introduces subtle issues to ports. I am now confused and torn as to which behavior should be preferable. On one hand it's easier to patch the port gcc-s to match the base one. On the other hand the default gcc behavior would save many lines in port makefiles that explicitly add -I ${LOCALBASE}/include or some such to CFLAGS. buildworld and buildkernel (and etc) could be spared from any interference from /usr/local by using -nostdinc and explicitly setting all necessary include paths. Adding more people to conversation in hope that it could become fruitful. -- Andriy Gapon