Date: Fri, 1 Apr 2016 16:35:26 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com> Cc: Dimitry Andric <dim@freebsd.org>, Bryan Drewery <bdrewery@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Gerald Pfeifer <gerald@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Message-ID: <5334F356-982F-40CA-9009-41B59AAC8665@dsl-only.net> In-Reply-To: <CANCZdfoa3kth8USvLXXrzAO5KgbizN29WCj4ebb02=Nj75ZU6A@mail.gmail.com> 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> <DD2A166A-28D3-4F97-A084-6109B0BA21CC@bsdimp.com> <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> <CANCZdfoa3kth8USvLXXrzAO5KgbizN29WCj4ebb02=Nj75ZU6A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc has for the default include search places:] powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in /usr/local/include before /usr/include : see below. > # portmaster --list-origins > . . . > devel/powerpc64-xtoolchain-gcc > . . . > > # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version > powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for powerpc64) 5.3.0 > Copyright (C) 2015 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ - -o /dev/null > . . . > ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0" > ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/powerpc64-portbld-freebsd11.0" > ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../include/c++/5.3.0/backward" > ignoring nonexistent directory "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerpc64-portbld-freebsd11.0/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include > /usr/local/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed > /usr/include > End of search list. > . . . === Mark Millard markmi at dsl-only.net On 2016-Apr-1, at 7:25 AM, Warner Losh <imp at bsdimp.com> wrote: > > > > On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <dim@freebsd.org> wrote: > On 01 Apr 2016, at 00:44, Warner Losh <imp@bsdimp.com> wrote: > > > >> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrewery@freebsd.org> 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’s one of the maddening inconsistencies 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 wish > >> /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’t. That’s another 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5334F356-982F-40CA-9009-41B59AAC8665>