From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 16:21:05 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 A1671106564A for ; Fri, 6 Jul 2012 16:21:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f182.google.com (mail-gh0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 54B558FC0A for ; Fri, 6 Jul 2012 16:21:05 +0000 (UTC) Received: by ghbz22 with SMTP id z22so10222210ghb.13 for ; Fri, 06 Jul 2012 09:21:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=EKOk7RAoBL82Hv0SI9Gwteh7SoZeEwVX3C4Dnwv8w+o=; b=AA7wrHElJ7dPQOWRj0tk2zg6P1YmL+8UyPjEdtZSDMnnTSGUkjbxCF2ixeV9YrGF3W YPHTvBxsnI8wPp758VY9hvcRjvCMYlzhVhqt0OWfwkdfJIxMD6eWnN3a6uFIDQTOlg91 XKQ/6Zp/v5HxCPdlH524EERX+Kur7uLp7Qf6bt7dfb/UPz0D2nuIbS4NawL2of13wbf+ 6TgV/c/Kpw7ToMvekXEkcHKezSZ9Yls0xPo/9gku2eUDsJg8/s2UjkRKJx4fCUKp4/1y zEXRKjx+YUv1tuQOCEP+waG2Xef3rTQqywkhKMhKa0YGRWe/YjKs0dH5tVGUQd1um2TF nwxA== Received: by 10.60.30.101 with SMTP id r5mr31791893oeh.68.1341591664561; Fri, 06 Jul 2012 09:21:04 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id jn2sm18885322obb.13.2012.07.06.09.21.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 09:21:03 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4FF700CF.2000206@FreeBSD.org> Date: Fri, 6 Jul 2012 10:21:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1DED79CC-CACD-4D22-9F1F-E3EB17938EB6@bsdimp.com> References: <4FF60A9E.5070503@FreeBSD.org> <4FF6DB51.40904@FreeBSD.org> <508B8B4E-DF5E-412B-BD2B-86F21EBF4C8C@bsdimp.com> <4FF700CF.2000206@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkXCIHegUTxReXUWzUX8LvmE4onfg0dYegRceCFC8zCLu96M7kgozu01/sMctTYGdS9KfLS 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:21:05 -0000 On Jul 6, 2012, at 9:14 AM, Andriy Gapon wrote: > on 06/07/2012 18:10 Warner Losh said the following: >> I think it shouldn't be there. It is non-standard behavior both in = the gcc world and in the freebsd world. It does save a little on = makefiles on some ports, but most ports already grok things are in = /usr/local or opt/local and cope. >=20 > Please define the non-standard behavior. Just curious if you opened = the link. 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. Warner >> On Jul 6, 2012, at 6:34 AM, Andriy Gapon wrote: >>=20 >>>=20 >>> Inviting wider audience to the discussion. >>>=20 >>> -------- Original Message -------- >>> Date: Fri, 06 Jul 2012 00:43:58 +0300 >>> From: Andriy Gapon >>> Subject: Re: gcc46 header search path >>>=20 >>> on 05/07/2012 17:15 Andriy Gapon said the following: >>>>=20 >>>> Gerald, >>>>=20 >>>> while thinking what to reply in our other conversation I ran into = another issue >>>> with gcc46: >>>>=20 >>>> $ 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] >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Adding more people to conversation in hope that it could become = fruitful. >>>=20 >>>=20 >>> --=20 >>> Andriy Gapon >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> freebsd-toolchain@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >>> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >>=20 >=20 >=20 > --=20 > Andriy Gapon >=20 >=20