Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 3/31/16 2:23 PM, Mark Millard wrote: > Should there be xtoolchain usage notes about avoiding /usr/local/include name > conflicts and/or about how to assign CC/CXX/XCC/XCXX? > > As long as I use gcc49 tools for CC and CXX I still must do things like > renaming files in /usr/local/include to avoid them interfering with system > headers: Try setting X_COMPILER_TYPE=gcc as well. -- Regards, Bryan Drewery ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
The src.conf that I listed in the original message included the line: > X_COMPILER_TYPE=gcc So I'd already done that. Other suggestions? === Mark Millard markmi at dsl-only.net On 2016-Mar-31, at 2:26 PM, Bryan Drewery wrote: On 3/31/16 2:23 PM, Mark Millard wrote: > Should there be xtoolchain usage notes about avoiding /usr/local/include name > conflicts and/or about how to assign CC/CXX/XCC/XCXX? > > As long as I use gcc49 tools for CC and CXX I still must do things like > renaming files in /usr/local/include to avoid them interfering with system > headers: Try setting X_COMPILER_TYPE=gcc as well. -- Regards, Bryan Drewery ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
Recent changes have been trying to make things like
powerpc64-xtoolchain-gcc/powerpc64-gcc work better for buildworld/buildkernel.
I happen to do this on a powerpc64 context so the "cross build" is actually
self-hosted. No gcc 4.2.1 is present and clang 3.8.0 and before have code
generation problems for powerpc64 and powerpc so I avoid it for system builds,
including for stage 3. (Also, clang for powerpc64 does not support building
libstand: no soft-float support.)
As of my last test (-r297465) buildworld's stage 3 failed from implicit use of
/usr/local/include materials unless I renamed various files there. In part this
is because of my using gcc49 tools for CC and for CXX while using the
powerpc64-gcc tools only for XCC and XCXX.
Is there a standard or recommended way to configure things to avoid such
issues? Should powerpc64-gcc use be forced for CC and CXX as well as XCC and
XCXX?
Should there be xtoolchain usage notes about avoiding /usr/local/include name
conflicts and/or about how to assign CC/CXX/XCC/XCXX?
As long as I use gcc49 tools for CC and CXX I still must do things like
renaming files in /usr/local/include to avoid them interfering with system
headers:
> # find /usr/local/include/ -name 'renamed*' -print
> /usr/local/include/renamed_dwarf.h
> /usr/local/include/atf-c/renamed_defs.h
> /usr/local/include/renamed_iconv.h
> /usr/local/include/renamed_libdwarf.h
> /usr/local/include/renamed_histedit.h
I use the likes of:
> # diff -rq /usr/include /usr/local/include | grep "^Files "
to find what to rename for the duration of the system builds.
An example of what happens without the renames is below but I first note the
use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include (shown
after the .h file rename but the build was with the normal file name):
> # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
> #define dwarf_errmsg(error) dwarf_errmsg_(&error)
> const char*dwarf_errmsg_(Dwarf_Error *);
> /usr/include/libdwarf.h
> # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print
> char* dwarf_errmsg(Dwarf_Error/*error*/);
> /usr/local/include/renamed_libdwarf.h
> #
So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from
/usr/include .
The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and
dwarf_errmsg being undefined (dwarf_errno has similar issues):
> --
> >>> stage 3: cross tools
> --
> . . .
> --- ctfconvert.full ---
> /usr/local/bin/gcc49 -O2 -pipe
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include
> -I/usr/src/cddl/usr.b
> in/ctfconvert/../../../cddl/contrib/opensolaris
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head
> -I/us
> r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>
> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
> -I/usr/src/cddl/usr.bin/ctfconvert/.
> ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g
> -std=gnu99
> -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
> -static -L/usr/obj/xtoolchain/powerpc.power
> pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o ctfconvert.o
> dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o memory.o merge.o
> output.o st_parse.o stabs.o stack.o strtab.o symbol
> .o tdata.o traverse.o util.o -ldwarf -lelf -lelf -lz -lpthread -legacy
> dwarf.o: In function `die_off':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
> undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_sibling':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:288:
> undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_child':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:305:
> undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_tag':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:319:
> undefined reference to `dwarf_errmsg'
> dwarf.o: In function `die_unsigned':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:370:
> undefined reference to `dwarf_errmsg'
> dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418:
> more undefined references to `dwarf_errmsg' follow
> dwarf.o: In function `dw_read':
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1963:
> undefined reference to `dwarf_errno'
> /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensol
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 3/31/16 2:23 PM, Mark Millard wrote:
> I use the likes of:
>
>> > # diff -rq /usr/include /usr/local/include | grep "^Files "
> to find what to rename for the duration of the system builds.
>
> An example of what happens without the renames is below but I first note the
> use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include (shown
> after the .h file rename but the build was with the normal file name):
>
Except for legacy, build-tools, bootstrap-tools, and cross-tools, none
of /usr/include or /usr/local/include is supposed to be included. In
those phases though it is intended that /usr/include is used. Not
/usr/local/include though.
What package is providing /usr/local/include/libdwarf.h? 'pkg which
/usr/local/include/libdwarf.h' I ask so I can install it and recreate
the issue and fix it.
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.
>> > # find /usr/include/ -exec grep dwarf_errmsg {} \; -print
>> > #definedwarf_errmsg(error) dwarf_errmsg_(&error)
>> > const char *dwarf_errmsg_(Dwarf_Error *);
>> > /usr/include/libdwarf.h
>> > # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print
>> > char* dwarf_errmsg(Dwarf_Error/*error*/);
>> > /usr/local/include/renamed_libdwarf.h
>> > #
> So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from
> /usr/include .
>
> The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and
> dwarf_errmsg being undefined (dwarf_errno has similar issues):
>
>> > --
> > >>> stage 3: cross tools
>> > --
>> > . . .
>> > --- ctfconvert.full ---
>> > /usr/local/bin/gcc49 -O2 -pipe
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include
>> > -I/usr/src/cddl/usr.b
>> > in/ctfconvert/../../../cddl/contrib/opensolaris
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris
>> > -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head
>> > -I/us
>> > r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>> -I/usr/src/cddl/usr.bin/ctfconvert/.
>> > ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g
>> > -std=gnu99
>> > -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
>> > -static -L/usr/obj/xtoolchain/powerpc.power
>> > pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o
>> > ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o
>> > memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol
>> > .o tdata.o traverse.o util.o -ldwarf -lelf -lelf -lz -lpthread
>> > -legacy
>> > dwarf.o: In function `die_off':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
>> > undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_sibling':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:288:
>> > undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_child':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:305:
>> > undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_tag':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:319:
>> > undefined reference to `dwarf_errmsg'
>> > dwarf.o: In function `die_unsigned':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:370:
>> > undefined reference to `dwarf_errmsg'
>> > dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418:
>> > more undefined references to `dwarf_errmsg' follow
>> > dwarf.o: In function `dw_read':
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1963:
>> > undefined reference to `dwarf_errno'
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1971:
>> > undefined reference to `dwarf_errmsg'
>> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1977:
>> > undefined reference to `dwarf_errmsg'
>> > collect2: error: ld returned 1 exit status
>> > *** [ctfconvert.full] Error code 1
>
--
Regards,
Bryan Drewery
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
> On 2016-Mar-31, at 2:32 PM, Bryan Drewery wrote:
>
> On 3/31/16 2:23 PM, Mark Millard wrote:
>> I use the likes of:
>>
# diff -rq /usr/include /usr/local/include | grep "^Files "
>> to find what to rename for the duration of the system builds.
>>
>> An example of what happens without the renames is below but I first note the
>> use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include
>> (shown after the .h file rename but the build was with the normal file name):
>>
>
> Except for legacy, build-tools, bootstrap-tools, and cross-tools, none
> of /usr/include or /usr/local/include is supposed to be included. In
> those phases though it is intended that /usr/include is used. Not
> /usr/local/include though.
>
> What package is providing /usr/local/include/libdwarf.h? 'pkg which
> /usr/local/include/libdwarf.h' I ask so I can install it and recreate
> the issue and fix it.
Here is the list for the things I renamed, including for dwarf.h :
> # pkg which /usr/local/include/dwarf.h /usr/local/include/libdwarf.h
> /usr/local/include/atf-c/defs.h /usr/local/include/iconv.h
> /usr/local/include/histedit.h
> /usr/local/include/dwarf.h was installed by package libdwarf-20130207
> /usr/local/include/libdwarf.h was installed by package libdwarf-20130207
> /usr/local/include/atf-c/defs.h was installed by package atf-0.21
> /usr/local/include/iconv.h was not found in the database
> /usr/local/include/histedit.h was installed by package libedit-3.1.20150325_1
It looks like iconv.h is from something later removed but was not cleaned out
at the time. I have /usr/local/include/readline/ material from the same time
frame:
> # ls -lt /usr/local/include/
> .. . .
> -rw-r--r-- 1 root wheel 12733 Apr 22 2015 mpc.h
> -rw-r--r-- 1 root wheel9348 Mar 12 2015 renamed_iconv.h
> drwxr-xr-x 2 root wheel 512 Mar 12 2015 readline
> # ls -lt /usr/local/include/readline
> total 80
> -rw-r--r-- 1 root wheel 3193 Mar 12 2015 rltypedefs.h
> -rw-r--r-- 1 root wheel 2438 Mar 12 2015 rlconf.h
> -rw-r--r-- 1 root wheel 1835 Mar 12 2015 rlstdc.h
> -rw-r--r-- 1 root wheel 3046 Mar 12 2015 tilde.h
> -rw-r--r-- 1 root wheel 10079 Mar 12 2015 history.h
> -rw-r--r-- 1 root wheel 3163 Mar 12 2015 keymaps.h
> -rw-r--r-- 1 root wheel 4577 Mar 12 2015 chardefs.h
> -rw-r--r-- 1 root wheel 37802 Mar 12 2015 readline.h
but "pkg which" reports those files as being from readline-6.3.8 .
I guess I can just delete would would normally have been
/usr/local/include/iconv.h .
Back to quoting the earlier message:
> 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.
>
# find /usr/include/ -exec grep dwarf_errmsg {} \; -print
#definedwarf_errmsg(error) dwarf_errmsg_(&error)
const char *dwarf_errmsg_(Dwarf_Error *);
/usr/include/libdwarf.h
# find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print
char* dwarf_errmsg(Dwarf_Error/*error*/);
/usr/local/include/renamed_libdwarf.h
#
>> So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from
>> /usr/include .
>>
>> The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and
>> dwarf_errmsg being undefined (dwarf_errno has similar issues):
>>
--
>> stage 3: cross tools
--
. . .
--- ctfconvert.full ---
/usr/local/bin/gcc49 -O2 -pipe
-I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris
-I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include
-I/usr/src/cddl/usr.b
in/ctfconvert/../../../cddl/contrib/opensolaris
-I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris
-I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head
-I/us
r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common
>>> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt
>>> -I/usr/src/cddl/usr.bin/ctfconvert/.
./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g
-std=gnu99
-I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
-static -L/usr/obj/xtoolchain/powerpc.power
pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o
ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o
memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol
.o tdata.o traverse.o util.o -ldwarf -lelf -lelf -lz -lpthread
-legacy
dwarf.o: In function `die_off':
/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270:
undefined reference to `dwarf_errmsg'
dwa
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
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
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
> On Mar 31, 2016, at 4:34 PM, Bryan Drewery 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. > 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. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 2016-Mar-31, at 3:34 PM, Bryan Drewery 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.hppc-asm.h > spu2vmx.h stdatomic.h stdint-gcc.h > unwind.h > float.h objcppu_intrinsics.h > ssp stdbool.h stdint.h > varargs.h > htmintrin.h omp.h si2vmx.h > stdalign.h stddef.hstdnoreturn.h > vec_types.h > htmxlintrin.h paired.hspe.h > stdarg.hstdfix.htgmath.h > > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed: > READMElibmilter limits.hnetinet > stddef.hstdio.h stdlib.hsys syslimits.h > unistd.hwchar.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 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/l
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 3/31/16 4:42 PM, Mark Millard wrote: > On 2016-Mar-31, at 3:34 PM, Bryan Drewery 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.hppc-asm.h >> > spu2vmx.h stdatomic.h stdint-gcc.h >> > unwind.h >> > float.hobjcppu_intrinsics.h >> > ssp stdbool.h stdint.h >> > varargs.h >> > htmintrin.homp.h si2vmx.h >> > stdalign.h stddef.hstdnoreturn.h >> > vec_types.h >> > htmxlintrin.h paired.hspe.h >> > stdarg.hstdfix.htgmath.h >> > >> > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed: >> > README libmilter limits.hnetinet >> > stddef.hstdio.h stdlib.hsys >> > syslimits.h unistd.hwchar.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. This should be fine with my fix too. Trying add this to your make.conf for now: CFLAGS.gcc+= -isystem /usr/include -- Regards, Bryan Drewery ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > This should be fine with my fix too. > > Trying add this to your make.conf for now: > > CFLAGS.gcc+= -isystem /usr/include I'll try that. But just FYI: here are the lists of files from gcc49 that having /usr/include first will change what gcc49 sets up for itself and has been using in my past activities (spanning both 4.9.4/include/ and 4.9.4/include-fixed/ ): > # diff -rq /usr/include/ > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ | grep > "^Files " > Files /usr/include/float.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/float.h > differ > Files /usr/include/iso646.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/iso646.h > differ > Files /usr/include/ssp/ssp.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/ssp.h > differ > Files /usr/include/ssp/stdio.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/stdio.h > differ > Files /usr/include/ssp/string.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/string.h > differ > Files /usr/include/ssp/unistd.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/unistd.h > differ > Files /usr/include/stdalign.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdalign.h > differ > Files /usr/include/stdarg.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdarg.h > differ > Files /usr/include/stdatomic.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdatomic.h > differ > Files /usr/include/stdbool.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdbool.h > differ > Files /usr/include/stddef.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stddef.h > differ > Files /usr/include/stdint.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdint.h > differ > Files /usr/include/stdnoreturn.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdnoreturn.h > differ > Files /usr/include/tgmath.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/tgmath.h > differ > Files /usr/include/varargs.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/varargs.h > differ > # diff -rq /usr/include/ > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/ | > grep "^Files " > Files /usr/include/libmilter/mfapi.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/libmilter/mfapi.h > differ > Files /usr/include/limits.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/limits.h > differ > Files /usr/include/netinet/ip_fil.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_fil.h > differ > Files /usr/include/netinet/ip_lookup.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_lookup.h > differ > Files /usr/include/netinet/ip_nat.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_nat.h > differ > Files /usr/include/netinet/ip_proxy.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_proxy.h > differ > Files /usr/include/netinet/ip_scan.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_scan.h > differ > Files /usr/include/netinet/ip_state.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/netinet/ip_state.h > differ > Files /usr/include/stddef.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/stddef.h > differ > Files /usr/include/stdio.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/stdio.h > differ > Files /usr/include/stdlib.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/stdlib.h > differ > Files /usr/include/sys/types.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/sys/types.h > differ > Files /usr/include/unistd.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/unistd.h > differ > Files /usr/include/wchar.h and > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed/wchar.h > differ === Mark Millard mar...@dsl-only.net On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: On 3/31/16 4:42 PM, Mark Millard wrote: > On 2016-Mar-31, at 3:34 PM, Bryan Drewery 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_
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > This should be fine with my fix too. > > Trying add this to your make.conf for now: > > CFLAGS.gcc+= -isystem /usr/include [Context note: I normally use: > WITHOUT_CROSS_COMPILER= > # > WITH_FAST_DEPEND= > WITH_LIBCPLUSPLUS= > WITH_BOOT= > WITH_CLANG= > WITH_CLANG_IS_CC= > WITH_CLANG_FULL= > WITH_LLDB= so clang is built by powerpc64-gcc's tools even though clang is not used for the build. ] The result was almost immediate build failure: > --- _bootstrap-tools-lib/clang/libllvmsupport --- > --- APFloat.o --- > In file included from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/AlignOf.h:19:0, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:18, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Allocator.h:24, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:18, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Host.h:17, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/Hashing.h:49, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:13, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20, > from > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15: > /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: '::max_align_t' has > not been declared >using ::max_align_t; ^ === Mark Millard markmi at dsl-only.net On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > On 3/31/16 4:42 PM, Mark Millard wrote: >> On 2016-Mar-31, at 3:34 PM, Bryan Drewery 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.hppc-asm.h spu2vmx.h stdatomic.h stdint-gcc.h unwind.h float.hobjcppu_intrinsics.h ssp stdbool.h stdint.h varargs.h htmintrin.homp.h si2vmx.h stdalign.h stddef.hstdnoreturn.h vec_types.h htmxlintrin.h paired.hspe.h stdarg.hstdfix.htgmath.h /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed: README libmilter limits.hnetinet stddef.hstdio.h stdlib.hsys syslimits.h unistd.hwchar.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. > > This should be fine with my fix too. > > Trying add this to your make.conf for now: > > CFLAGS.gcc+= -isystem /usr/include > -- Regards, Bryan Drewery ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
On 2016-Mar-31, at 8:14 PM, Mark Millard wrote: > > On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > >> This should be fine with my fix too. >> >> Trying add this to your make.conf for now: >> >> CFLAGS.gcc+= -isystem /usr/include > > [Context note: I normally use: > >> WITHOUT_CROSS_COMPILER= >> # >> WITH_FAST_DEPEND= >> WITH_LIBCPLUSPLUS= >> WITH_BOOT= >> WITH_CLANG= >> WITH_CLANG_IS_CC= >> WITH_CLANG_FULL= >> WITH_LLDB= > > > so clang is built by powerpc64-gcc's tools even though clang is not used for > the build. > ] > > The result was almost immediate build failure: > >> --- _bootstrap-tools-lib/clang/libllvmsupport --- >> --- APFloat.o --- >> In file included from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/AlignOf.h:19:0, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:18, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Allocator.h:24, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/StringMap.h:18, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Host.h:17, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/Hashing.h:49, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:13, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20, >> from >> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15: >> /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: '::max_align_t' has >> not been declared >> using ::max_align_t; > ^ > > === > Mark Millard > markmi at dsl-only.net I added using -v in CFLAGS.gcc in order for it to report include search paths. The last one of reported in the script output looks like: > ignoring nonexistent directory > "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../../powerpc64-portbld-freebsd11.0/include" > ignoring duplicate directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support > . > > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include > /usr/include > /usr/local/lib/gcc49/include/c++/ > /usr/local/lib/gcc49/include/c++//powerpc64-portbld-freebsd11.0 > /usr/local/lib/gcc49/include/c++//backward > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include > /usr/local/include > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed > End of search list. I appears that C++ needs its own override for where to find C++ header before looking in the gcc49 specific places. These sorts of odd, hard to avoid dependencies are part of why I asked if there was a standard/recommend assignment to use for CC/XCC: I was hoping there was a known-good way to compile that avoided the issues, possibly by using powerpc64-gcc tools for CC/XCC as well. FYI: The last C compile in this script output lists: > ignoring nonexistent directory > "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../../powerpc64-portbld-freebsd11.0/include" > ignoring duplicate directory "/usr/include" > ignoring duplicate directory > "/usr/src/kerberos5/tools/make-roken/../../include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/kerberos5/tools/make-roken/../../include > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include > /usr/include > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include > /usr/local/include > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed > End of search list. === Mark Millard markmi at dsl-only.net On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > On 3/31/16 4:42 PM, Mark Millard wrote: >> On 2016-Mar-31, at 3:34 PM, Bryan Drewery 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 o
