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 >Received on Thu Mar 31 2016 - 21:42:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC