svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

Thu Mar 31 23:42:51 UTC 2016

On 2016-Mar-31, at 3:34 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc49/include/c++/
> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
> /usr/local/lib/gcc49/include/c++//backward
> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
> /usr/local/include
> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
> /usr/include
> End of search list.

Beyond /usr/local/include is also the fun of [ignoring C++ specific issues]:
(My quoting of a copy/paste)

> # ls /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include*
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include:
> altivec.h		iso646.h		ppc-asm.h		spu2vmx.h		stdatomic.h		stdint-gcc.h		unwind.h
> float.h			objc			ppu_intrinsics.h	ssp			stdbool.h		stdint.h		varargs.h
> htmintrin.h		omp.h			si2vmx.h		stdalign.h		stddef.h		stdnoreturn.h		vec_types.h
> htmxlintrin.h		paired.h		spe.h			stdarg.h		stdfix.h		tgmath.h
> 
> /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed:
> README		libmilter	limits.h	netinet		stddef.h	stdio.h		stdlib.h	sys		syslimits.h	unistd.h	wchar.h

But at least in recent times after WCHAR_TYPE was fixed for powerpc/powerpc64 I've not had troubles that traced to these for CC and CXX being based on gcc49 while XCC and XCXX were based on powerpc64-gcc for buildworld/buildkernel on a powerpc64 host.

I have had various examples of /usr/local/include/ files breaking builds depending on what ports were in place at the time. All along I've been doing renaming in that area to allow buildworld/buildkernel use.

===
Mark Millard
markmi at dsl-only.net

Message history:

On 2016-Mar-31, at 3:34 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> 
> On 3/31/16 3:02 PM, Mark Millard wrote:
>>>> We likely just need to prioritize /usr/include over /usr/local/include
>>>> for these phases, which gcc49 may have backwards since it has its prefix
>>>> set to /usr/local from the ports build.
> 
> Yup this is the problem with using the ports compiler as the "host"
> compiler:
> 
>> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/gcc49
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/lto-wrapper
>> Target: x86_64-portbld-freebsd11.0
>> Configured with: ./../gcc-4.9-20160210/configure --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 --build=x86_64-portbld-freebsd11.0
>> Thread model: posix
>> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)
>> COLLECT_GCC_OPTIONS='-v' '-o' '/dev/null' '-mtune=generic' '-march=x86-64'
>> /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus -quiet -v - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -version -o /tmp//ccA75yFy.s
>> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) (x86_64-portbld-freebsd11.0)
>>        compiled by GNU C version 4.9.4 20160210 (prerelease), GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.3
>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>> ignoring nonexistent directory "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/local/lib/gcc49/include/c++/
>> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>> /usr/local/lib/gcc49/include/c++//backward
>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>> /usr/local/include
>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
>> /usr/include
>> End of search list.
> 
> Note the /usr/local/include and /usr/include order near the end.
> 
> Passing -isystem /usr/include seems to fix it:
> 
>> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null -isystem /usr/include
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/gcc49
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/lto-wrapper
>> Target: x86_64-portbld-freebsd11.0
>> Configured with: ./../gcc-4.9-20160210/configure --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc49 --libexecdir=/usr/local/libexec/gcc49 --program-suffix=49 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc49/include/c++/ --with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection' --with-system-zlib --with-ecj-jar=/usr/local/share/java/ecj-4.5.jar --enable-languages=c,c++,objc,fortran,java --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/info/gcc49 --build=x86_64-portbld-freebsd11.0
>> Thread model: posix
>> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)
>> COLLECT_GCC_OPTIONS='-v' '-o' '/dev/null' '-isystem' '/usr/include' '-mtune=generic' '-march=x86-64'
>> /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus -quiet -v -isystem /usr/include - -quiet -dumpbase - -mtune=generic -march=x86-64 -auxbase - -version -o /tmp//ccNh006Z.s
>> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) (x86_64-portbld-freebsd11.0)
>>        compiled by GNU C version 4.9.4 20160210 (prerelease), GMP version 5.1.3, MPFR version 3.1.3, MPC version 1.0.3
>> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
>> ignoring nonexistent directory "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include"
>> ignoring duplicate directory "/usr/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/include
>> /usr/local/lib/gcc49/include/c++/
>> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>> /usr/local/lib/gcc49/include/c++//backward
>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>> /usr/local/include
>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
> 
> 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.
> 
> 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.
> 
> 
> 
> -- 
> Regards,
> Bryan Drewery
> 