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 > . . . >=20 > # /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. >=20 > # 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/../../../../includ= e/c++/5.3.0" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/powerpc64-portbld-freebsd11.0" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/backward" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-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. > . . . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-1, at 7:25 AM, Warner Losh <imp at bsdimp.com> wrote: >=20 >=20 >=20 > 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=E2=80=99s 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. >=20 > 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... :) >=20 > That's why it shouldn't be *FIRST*, not why it shouldn't be there > at all. >=20 > >> 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=E2=80=99t. That=E2=80=99s = 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. >=20 > 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. >=20 > 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. > =20 > 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. >=20 > 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. >=20 > Warner =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5334F356-982F-40CA-9009-41B59AAC8665>