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 From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 15:10:41 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 A3A771065675 for ; Fri, 6 Jul 2012 15:10:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 70E878FC0A for ; Fri, 6 Jul 2012 15:10:38 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so15821616pbb.13 for ; Fri, 06 Jul 2012 08:10:37 -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=C/Bw7lyf9CRxYvqfXWSVDHtE4yyZkRMRRuyXYtymhk8=; b=D5dSYxcLkCgLL/aWlHvx0XRj8PCS21+N/VqZ4dGgLGb0W4RBxfm42AesTymEtgbdzu kx9kX2FRPEIYECIpKvLKASYTcgN/5r1kdi7Fl6sH0MFWEzT8E8Y8751r6YXsjBQ+KPz4 UfKfB3sS+GWmGBD3LDpUdZkkTYB4k9CoB8YsQc5tjdfuj56qadA53VtqpNyWGFqyAD64 ov7txfHQptHvopdm/bubHzxb0Hz3cNBxJg8vYWzqM0Bx1PbCezTpcsLLET9VKM/8ox79 CBvspeeEdgH4LlVUWMDW0zuo2GVxUdM0WRzFQ1aWPKBSA/wpO8sepv2QT3/ByjfNfC0h fiAg== Received: by 10.68.221.74 with SMTP id qc10mr37309774pbc.31.1341587437843; Fri, 06 Jul 2012 08:10:37 -0700 (PDT) Received: from [10.0.0.63] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id rg9sm22023837pbc.67.2012.07.06.08.10.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 08:10:37 -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: <4FF6DB51.40904@FreeBSD.org> Date: Fri, 6 Jul 2012 09:10:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <508B8B4E-DF5E-412B-BD2B-86F21EBF4C8C@bsdimp.com> References: <4FF60A9E.5070503@FreeBSD.org> <4FF6DB51.40904@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnGwRfZiMeeSLOq06DWJk4130TkmfXWjAYhDmt22/jvkqaxwub4RlZGVaRPnFGlbl6Sp5lL 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 15:10:41 -0000 Top posting, because I'm lame... 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. Warner On Jul 6, 2012, at 6:34 AM, Andriy Gapon wrote: >=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" From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 15:14:27 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 6E28E1065672 for ; Fri, 6 Jul 2012 15:14:27 +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 B90F58FC08 for ; Fri, 6 Jul 2012 15:14: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 SAA07818; Fri, 06 Jul 2012 18:14:23 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4FF700CF.2000206@FreeBSD.org> Date: Fri, 06 Jul 2012 18:14:23 +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> In-Reply-To: <508B8B4E-DF5E-412B-BD2B-86F21EBF4C8C@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 15:14:27 -0000 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. Please define the non-standard behavior. Just curious if you opened the link. > On Jul 6, 2012, at 6:34 AM, Andriy Gapon wrote: > >> >> 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 >> >> >> >> _______________________________________________ >> 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" > -- Andriy Gapon 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 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 From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 19:11:44 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 53C1A1065673; Fri, 6 Jul 2012 19:11:44 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4408FC14; Fri, 6 Jul 2012 19:11:44 +0000 (UTC) Received: from c120.sec.cl.cam.ac.uk (c120.sec.cl.cam.ac.uk [128.232.18.120]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q66JBfUn033202 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 6 Jul 2012 19:11:42 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <4FF7182A.9070803@FreeBSD.org> Date: Fri, 6 Jul 2012 20:11:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> 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> <4FF7182A.9070803@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) 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 19:11:44 -0000 On 6 Jul 2012, at 17:54, Andriy Gapon wrote: > 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. Why? The number one question I get from developers new FreeBSD is 'I = wanted to use libfoo from ports, I stalled it, and now [gcc,clang] = doesn't find the headers, why not?' No one has yet provided me with a = sane reason why our system compiler would not look in the standard = locations where we install headers and libraries. Running configure = scripts on FreeBSD is a colossal pain because of this - you often need = to explicitly say -with-foo-include=3D/usr/local/include = -with-foo-lib=3D/usr/local/lib for an arbitrary number of values of foo, = depending on the library. Please, please, please, can we put our standard library and header paths = in the compiler standard header or library paths, or can someone give me = a good reason other than 'it's a stupid idea' why we should force every = single program that anyone compiles on FreeBSD to do = CFLAGS=3D-I/usr/local/include LDFLAGS=3D-L/usr/local/lib? David= From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 20:45:03 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 61B6B1065673 for ; Fri, 6 Jul 2012 20:45:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id F37538FC0A for ; Fri, 6 Jul 2012 20:45:02 +0000 (UTC) Received: by yhfs35 with SMTP id s35so4221632yhf.13 for ; Fri, 06 Jul 2012 13:45:02 -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=Bm2+b8uN+IIZw17wFhGHQamSJAlL5gyZHXtEJANBZL4=; b=WvLzdHs+WbImrG2DMP4jFmElsdwrf0V7jMLNEv/HyU2bGS8K6UqCi6o5Ca2imuls/f xuvg4CMYA7xf8R7sCI5FUXQfFkqqPXAPeWUZDSM1sC6CtUfSZmBVB9Oj8Gug1sZuimaE jYo7F4URWFaYHQai6p9vUDpMugb4pTihzqPJCVrr8OtXuTptchUXVqGZpafqb18Z+aXS 2XQrMDm5UXtbsc0gVJRB4blRIUXPhM5u25DG9Kriq3Hwb7tzKNzcL6cxL7uiORH/u2Sj KG+n5c/wuDnt2zM7jmQsAAJRZat5rifzbw/ERvPBKRXeE+UFETZPLJnsMXec40IjH20x 9unw== Received: by 10.60.172.236 with SMTP id bf12mr28462868oec.23.1341607502480; Fri, 06 Jul 2012 13:45:02 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id bd4sm24170194obb.12.2012.07.06.13.45.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jul 2012 13:45:01 -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: <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> Date: Fri, 6 Jul 2012 14:44:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <4FF7182A.9070803@FreeBSD.org> <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> To: David Chisnall X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkkDmUGjmiSblUG4y/rIXJVYV5ezx4ULQzntRcUkrrp7vc6++2OzlFsU1fIksU41jas2H+R Cc: toolchain@FreeBSD.org, Andriy Gapon 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 20:45:03 -0000 On Jul 6, 2012, at 1:11 PM, David Chisnall wrote: > On 6 Jul 2012, at 17:54, Andriy Gapon wrote: >=20 >> 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. >=20 > Why? The number one question I get from developers new FreeBSD is 'I = wanted to use libfoo from ports, I stalled it, and now [gcc,clang] = doesn't find the headers, why not?' No one has yet provided me with a = sane reason why our system compiler would not look in the standard = locations where we install headers and libraries. Because they aren't standard locations. Or at least didn't used to be = standard locations. At this point, I'd say it is likely better to = include the new path than not, since it has become standard since = FreeBSD started tracking gcc. > Running configure scripts on FreeBSD is a colossal pain because of = this - you often need to explicitly say = -with-foo-include=3D/usr/local/include -with-foo-lib=3D/usr/local/lib = for an arbitrary number of values of foo, depending on the library. >=20 > Please, please, please, can we put our standard library and header = paths in the compiler standard header or library paths, or can someone = give me a good reason other than 'it's a stupid idea' why we should = force every single program that anyone compiles on FreeBSD to do = CFLAGS=3D-I/usr/local/include LDFLAGS=3D-L/usr/local/lib? The reasons are that /usr/local/include superceds anything in = /usr/include. This is dangerous. Users should get just the system = default libraries and headers when they compile unless they ask for = more. That's what makes it stupid. However, regardless of my opinion, I think this may be a case where the = avalanche has started, and it is too late for the snow flakes to vote. Warner From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 21:45:10 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 EBF94106566C; Fri, 6 Jul 2012 21:45:10 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id A38888FC15; Fri, 6 Jul 2012 21:45:05 +0000 (UTC) Received: from [192.168.0.6] (spaceball.home.andric.com [192.168.0.6]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 1FC175C59; Fri, 6 Jul 2012 23:45:04 +0200 (CEST) Message-ID: <4FF75C5E.3020105@andric.com> Date: Fri, 06 Jul 2012 23:45:02 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120619 Thunderbird/14.0 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> <4FF7182A.9070803@FreeBSD.org> <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, David Chisnall , Andriy Gapon 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 21:45:11 -0000 On 2012-07-06 22:44, Warner Losh wrote: ... > The reasons are that /usr/local/include superceds anything in /usr/include. This is dangerous. Users should get just the system default libraries and headers when they compile unless they ask for more. That's what makes it stupid. Well, one issue is that it becomes tricky to *remove* /usr/local/include from the include path, if you so desire, since it's built-in... Unless you start fiddling with -nostdinc, but that is rather painful. From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 22:29:45 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 E300D106566C; Fri, 6 Jul 2012 22:29:45 +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 064388FC0A; Fri, 6 Jul 2012 22:29:44 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA09733; Sat, 07 Jul 2012 01:29:43 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SnH1z-0008wl-FI; Sat, 07 Jul 2012 01:29:43 +0300 Message-ID: <4FF766D6.5040909@FreeBSD.org> Date: Sat, 07 Jul 2012 01:29:42 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Chisnall 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> <4FF7182A.9070803@FreeBSD.org> <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> In-Reply-To: <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 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 22:29:46 -0000 on 06/07/2012 22:11 David Chisnall said the following: > On 6 Jul 2012, at 17:54, Andriy Gapon wrote: > >> 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. > > Why? The number one question I get from developers new FreeBSD is 'I wanted > to use libfoo from ports, I stalled it, and now [gcc,clang] doesn't find the > headers, why not?' No one has yet provided me with a sane reason why our > system compiler would not look in the standard locations where we install > headers and libraries. Running configure scripts on FreeBSD is a colossal > pain because of this - you often need to explicitly say > -with-foo-include=/usr/local/include -with-foo-lib=/usr/local/lib for an > arbitrary number of values of foo, depending on the library. > > Please, please, please, can we put our standard library and header paths in > the compiler standard header or library paths, or can someone give me a good > reason other than 'it's a stupid idea' why we should force every single > program that anyone compiles on FreeBSD to do CFLAGS=-I/usr/local/include > LDFLAGS=-L/usr/local/lib? I think that this is a dummy argument. One could easily want his LOCALBASE to be /opt and the real ports system should support that. So what ports currently do, they really have to do (assuming $LOCALBASE as opposed to /usr/local). So, repeating myself for Nth time, the real question is whether we have any good reason to deviate from upstream's default behavior. Nothing less, nothing more, IMO. -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Fri Jul 6 22:32:05 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 1582E1065670; Fri, 6 Jul 2012 22:32:05 +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 2E51E8FC08; Fri, 6 Jul 2012 22:32:03 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA09754; Sat, 07 Jul 2012 01:31:58 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SnH4A-0008wy-0X; Sat, 07 Jul 2012 01:31:58 +0300 Message-ID: <4FF7675D.9090609@FreeBSD.org> Date: Sat, 07 Jul 2012 01:31:57 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: Dimitry Andric 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> <4FF7182A.9070803@FreeBSD.org> <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> <4FF75C5E.3020105@andric.com> In-Reply-To: <4FF75C5E.3020105@andric.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: toolchain@FreeBSD.org, David Chisnall 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 22:32:05 -0000 on 07/07/2012 00:45 Dimitry Andric said the following: > On 2012-07-06 22:44, Warner Losh wrote: > ... >> The reasons are that /usr/local/include superceds anything in /usr/include. This is dangerous. Users should get just the system default libraries and headers when they compile unless they ask for more. That's what makes it stupid. > > Well, one issue is that it becomes tricky to *remove* /usr/local/include > from the include path, if you so desire, since it's built-in... Unless > you start fiddling with -nostdinc, but that is rather painful. > My opinion is that system builds (buildworld, buildkernel) must use -nostdinc. Other types of build should accept the state of matters. -- Andriy Gapon From owner-freebsd-toolchain@FreeBSD.ORG Sat Jul 7 08:21:08 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 1CFCF1065673; Sat, 7 Jul 2012 08:21:08 +0000 (UTC) (envelope-from theraven@freebsd.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id B6D568FC1A; Sat, 7 Jul 2012 08:21:07 +0000 (UTC) Received: from [192.168.0.2] (cpc2-cmbg15-2-0-cust445.5-4.cable.virginmedia.com [86.26.13.190]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id q678Kufa036491 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 7 Jul 2012 08:21:00 GMT (envelope-from theraven@freebsd.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: David Chisnall In-Reply-To: <4FF766D6.5040909@FreeBSD.org> Date: Sat, 7 Jul 2012 09:20:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7937CE7E-2583-4DAF-9782-37B82891D3FF@freebsd.org> 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> <4FF7182A.9070803@FreeBSD.org> <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> <4FF766D6.5040909@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1278) 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: Sat, 07 Jul 2012 08:21:08 -0000 On 6 Jul 2012, at 23:29, Andriy Gapon wrote: > I think that this is a dummy argument. One could easily want his = LOCALBASE to > be /opt and the real ports system should support that. So what ports = currently > do, they really have to do (assuming $LOCALBASE as opposed to = /usr/local). That's completely irrelevant. If a user installs things in a = non-standard location, then that user should expect to have to point = things that they build from source at that non-standard location. If, = however, a user installs things in the standard location, then this = should Just Work. =20 The workflow that I have seen where this fails: - User runs ./configure - Configure script says 'libpng is not installed!' - User installs libpng from ports / packages - User runs ./configure - Configure script says 'libpng is not installed!' - User sends me an email asking why they can't install on FreeBSD, = usually including a small whine that this works on their favourite Linux = distro. - I tell the user 'Oh, you need to say = --with-png-include=3D/usr/local/include --with-png-lib=3D/usr/local/lib' - User says 'Why doesn't the compiler that FreeBSD ships know where to = find headers and libraries that FreeBSD installs?' - I shrug. I assumed this was done for a sensible reason, but so far no one has = actually said what that reason is. In an ideal world, the system = compiler should be able to automatically find any headers and libraries = installed by any supported mechanism (ports, pkg_add, pkg add), but in = an almost-ideal world it should at least find them if they are in the = default locations. David= From owner-freebsd-toolchain@FreeBSD.ORG Sat Jul 7 08:27:56 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 1B999106564A; Sat, 7 Jul 2012 08:27:56 +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 2FC138FC14; Sat, 7 Jul 2012 08:27:54 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA14100; Sat, 07 Jul 2012 11:27:53 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1SnQMr-000Cw4-DS; Sat, 07 Jul 2012 11:27:53 +0300 Message-ID: <4FF7F307.4030507@FreeBSD.org> Date: Sat, 07 Jul 2012 11:27:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120620 Thunderbird/13.0.1 MIME-Version: 1.0 To: David Chisnall 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> <4FF7182A.9070803@FreeBSD.org> <714BF622-A1B3-4A4A-A8BC-DCA82B4434A2@FreeBSD.org> <4FF766D6.5040909@FreeBSD.org> <7937CE7E-2583-4DAF-9782-37B82891D3FF@freebsd.org> In-Reply-To: <7937CE7E-2583-4DAF-9782-37B82891D3FF@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 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: Sat, 07 Jul 2012 08:27:56 -0000 on 07/07/2012 11:20 David Chisnall said the following: > On 6 Jul 2012, at 23:29, Andriy Gapon wrote: > >> I think that this is a dummy argument. One could easily want his LOCALBASE to >> be /opt and the real ports system should support that. So what ports currently >> do, they really have to do (assuming $LOCALBASE as opposed to /usr/local). > > That's completely irrelevant. If a user installs things in a non-standard location, then that user should expect to have to point things that they build from source at that non-standard location. If, however, a user installs things in the standard location, then this should Just Work. > > The workflow that I have seen where this fails: > > - User runs ./configure > - Configure script says 'libpng is not installed!' > - User installs libpng from ports / packages > - User runs ./configure > - Configure script says 'libpng is not installed!' > - User sends me an email asking why they can't install on FreeBSD, usually including a small whine that this works on their favourite Linux distro. > - I tell the user 'Oh, you need to say --with-png-include=/usr/local/include --with-png-lib=/usr/local/lib' > - User says 'Why doesn't the compiler that FreeBSD ships know where to find headers and libraries that FreeBSD installs?' > - I shrug. So we talked about different things: creating/maintaining ports vs manually building software outside of port system. > I assumed this was done for a sensible reason, but so far no one has actually said what that reason is. In an ideal world, the system compiler should be able to automatically find any headers and libraries installed by any supported mechanism (ports, pkg_add, pkg add), but in an almost-ideal world it should at least find them if they are in the default locations. I agree. -- Andriy Gapon