Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists
I agree that my experiment is not what should be the 11.0-CURRENT official file
contents by any means: it would break other contexts/uses for sure.
But I expect it was appropriate to identify one thing that contributes to the
observed behavior of cc1plus reporting -std=c++11 as unrecognized. This does
end up being separate from why gcc 4.2.1's cc1plus is in use through buildworld
stage 1.2 in the first place (legacy and bootstrap-tools).
The only places that I see CC=${XCC} CXX=${XCXX} sorts of assignments for
picking up and using cross compilation tools are:
# $FreeBSD: head/Makefile.inc1 279328 2015-02-26 20:02:29Z emaste $
...
WMAKEENV+= CC=${XCC} ${XCFLAGS} CXX=${XCXX} ${XCFLAGS} ${XCXXFLAGS} \
...
WMAKE= ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1
DESTDIR=${WORLDTMP}
...
LIB32WMAKEFLAGS+= CC=${XCC} ${LIB32FLAGS} \
CXX=${XCXX} ${LIB32FLAGS} \
...
LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} ${LIB32WMAKEFLAGS} \
...
LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*:N_LDSCRIPTROOT=*} \
...
KMAKEENV= ${WMAKEENV}
KMAKE= ${KMAKEENV} ${MAKE} ${.MAKEFLAGS} ${KERNEL_FLAGS}
KERNEL=${INSTKERNNAME}
None of these appear to be involved in any of the following...
${_+_}cd ${.CURDIR}; ${BMAKE} legacy
...
${_+_}cd ${.CURDIR}; ${BMAKE} bootstrap-tools
...
${_+_}cd ${.CURDIR}; ${TMAKE} build-tools
...
${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools
${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools
...
${_+_}cd ${.CURDIR}; ${KTMAKE} kernel-tools
...
.for _dir in lib/ncurses/ncurses lib/ncurses/ncursesw lib/libmagic
cd ${.CURDIR}/${_dir}; \
WORLDTMP=${WORLDTMP} \
MAKEFLAGS=-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS} \
MAKEOBJDIRPREFIX=${LIB32_OBJTREE} ${MAKE} SSP_CFLAGS= DESTDIR= \
DIRPRFX=${_dir}/ -DNO_LINT -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no \
build-tools
.endfor
Also, unfortunately, WITHOUT_CLANG_BOOTSTRAP= mixed with WITH_CLANG= gets
bootstrap-tools time frame clang-compilation activity just by the structure of
Makefile.inc1 ...
# $FreeBSD: head/Makefile.inc1 279328 2015-02-26 20:02:29Z emaste $
...
_bt=_bootstrap-tools
...
# We need to build tblgen when we're building clang either as
# the bootstrap compiler, or as the part of the normal build.
.if ${MK_CLANG_BOOTSTRAP} != no || ${MK_CLANG} != no
_clang_tblgen= \
lib/clang/libllvmsupport \
lib/clang/libllvmtablegen \
usr.bin/clang/tblgen \
usr.bin/clang/clang-tblgen
${_bt}-usr.bin/clang/clang-tblgen: ${_bt}-lib/clang/libllvmtablegen
${_bt}-lib/clang/libllvmsupport
${_bt}-usr.bin/clang/tblgen: ${_bt}-lib/clang/libllvmtablegen
${_bt}-lib/clang/libllvmsupport
.endif
...
.for _tool in \
${_clang_tblgen} \
...
${_bt}-${_tool}: .PHONY .MAKE
${_+_}@${ECHODIR} === ${_tool} (obj,depend,all,install); \
cd ${.CURDIR}/${_tool} \
${MAKE} DIRPRFX=${_tool}/ obj \
${MAKE} DIRPRFX=${_tool}/ depend \
${MAKE} DIRPRFX=${_tool}/ all \
${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX}/legacy
install
bootstrap-tools: ${_bt}-${_tool}
.endfor
I've reverted to trying CROSS_TOOLCHAIN=powerpc64-gcc using
WITHOUT_CLANG_BOOTSTRAP= and WITHOUT_CLANG= since even without the -std=c++11
issue (via my experiment) it tries gcc 4.2.1 for compiling part of clang during
stage 1.2 --and that fails.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-16, at 04:51 AM, Warner Losh imp at bsdimp.com wrote:
On Mar 16, 2015, at 7:02 PM, Dimitry Andric dim at freebsd.org wrote:
On 16 Mar 2015, at 09:02, Mark Millard markmi at dsl-only.net wrote:
I found why gcc 4.2.1's cc1plus was getting -std=c++11 for the
CROSS_TOOLCHAIN=powerpc64-gcc compiles that involve WITH_CLANG= .
(WITHOUT_CLANG= does not get the unrecognized notices.) There is a global
assignment to CXXFLAGS for all compilers whenever clang.build.mk is in use
(showing my experimental change...):
# svnlite diff /usr/srcC/lib/clang/clang.build.mk
Index: /usr/srcC/lib/clang/clang.build.mk
===
--- /usr/srcC/lib/clang/clang.build.mk (revision 279514)
+++ /usr/srcC/lib/clang/clang.build.mk (working copy)
@@ -34,8 +34,8 @@
CFLAGS+= -DLLVM_DEFAULT_TARGET_TRIPLE=\${TARGET_TRIPLE}\ \
-DLLVM_HOST_TRIPLE=\${BUILD_TRIPLE}\ \
-DDEFAULT_SYSROOT=\${TOOLS_PREFIX}\
-CXXFLAGS+= -std=c++11 -fno-exceptions -fno-rtti
-CXXFLAGS.clang+= -stdlib=libc++
+CXXFLAGS+= -fno-exceptions -fno-rtti
+CXXFLAGS.clang+= -std=c++11 -stdlib=libc++
.PATH: ${LLVM_SRCS}/${SRCDIR}
It may be that the -fno-exceptions -fno-rtti are also suspect for being
not limited to clang contexts.
This is incorrect. Clang needs -std=c++11, otherwise it cannot
Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists
On Mar 16, 2015, at 7:02 PM, Dimitry Andric d...@freebsd.org wrote:
On 16 Mar 2015, at 09:02, Mark Millard mar...@dsl-only.net wrote:
I found why gcc 4.2.1's cc1plus was getting -std=c++11 for the
CROSS_TOOLCHAIN=powerpc64-gcc compiles that involve WITH_CLANG= .
(WITHOUT_CLANG= does not get the unrecognized notices.) There is a global
assignment to CXXFLAGS for all compilers whenever clang.build.mk is in use
(showing my experimental change...):
# svnlite diff /usr/srcC/lib/clang/clang.build.mk
Index: /usr/srcC/lib/clang/clang.build.mk
===
--- /usr/srcC/lib/clang/clang.build.mk (revision 279514)
+++ /usr/srcC/lib/clang/clang.build.mk (working copy)
@@ -34,8 +34,8 @@
CFLAGS+= -DLLVM_DEFAULT_TARGET_TRIPLE=\${TARGET_TRIPLE}\ \
-DLLVM_HOST_TRIPLE=\${BUILD_TRIPLE}\ \
-DDEFAULT_SYSROOT=\${TOOLS_PREFIX}\
-CXXFLAGS+= -std=c++11 -fno-exceptions -fno-rtti
-CXXFLAGS.clang+= -stdlib=libc++
+CXXFLAGS+= -fno-exceptions -fno-rtti
+CXXFLAGS.clang+= -std=c++11 -stdlib=libc++
.PATH: ${LLVM_SRCS}/${SRCDIR}
It may be that the -fno-exceptions -fno-rtti are also suspect for being
not limited to clang contexts.
This is incorrect. Clang needs -std=c++11, otherwise it cannot compile.
I suspect you also need WITHOUT_CLANG_BOOTSTRAP (and WITHOUT_GCC_BOOTSTRAP,
probably).
From earlier debugging, I’m pretty sure that the wrong g++ is being used in the
CROSS_TOOLCHAIN case. I’m in Japan right now on travel, so I haven’t been able
to track it down. WITHOUT_GCC_BOOTSTRAP should be implied in that case, but if
not, that might explain why...
Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists
Overall powerpc64-xtoolchain-gcc does not include its own libc++ for
powerpc64-gcc.
Overall, then, an as-is powerpc64-xtoolchain-gcc based powerpc/powerpc64 build
would need to be WITHOUT_CLANG= as far as I can tell. (buildworld/buildkernel
but excluding building the clang-based tool chain.)
Trying WITHOUT_CLANG= (in /etc/src.conf ) got further but failed with:
--- bt_split.So ---^M
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem
/usr/obj/usr/srcC/tmp/usr/include -L/usr/obj/usr/srcC/tmp/usr/lib -fpic -DPIC
-O2 -pipe -I/usr/srcC/lib/libc/include -I/usr/srcC/lib/libc/.
./../include -I/usr/srcC/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE
-I/usr/srcC/lib/libc/../../contrib/gdtoa
-I/usr/srcC/lib/libc/../../contrib/libc-vis -DINET6
-I/usr/obj/usr/srcC/lib/libc -I/us
r/srcC/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE
-I/usr/srcC/lib/libc/../libmd
-I/usr/srcC/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION
-I/usr/srcC/lib/libc/../../contrib/tzcode/st
dtime -I/usr/srcC/lib/libc/stdtime -I/usr/srcC/lib/libc/locale -DBROKEN_DES
-DPORTMAP -DDES_BUILTIN -I/usr/srcC/lib/libc/rpc -DYP -DNS_CACHING
-DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=gnu99 -fstack-
protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
-Wno-pointer-sign -c /usr/srcC/lib/libc/db/btree/bt_split.c -o bt_split.So^M
...
--- bt_split.So ---^M
/usr/srcC/lib/libc/db/btree/bt_split.c: In function '__bt_split':^M
/usr/srcC/lib/libc/db/btree/bt_split.c:240:8: error: dereferencing type-punned
pointer will break strict-aliasing rules [-Werror=strict-aliasing]^M
bt_preserve(t, *(pgno_t *)bl-bytes) == RET_ERROR)^M
^^M
/usr/srcC/lib/libc/db/btree/bt_split.c: In function 'bt_broot':^M
/usr/srcC/lib/libc/db/btree/bt_split.c:548:7: error: dereferencing type-punned
pointer will break strict-aliasing rules [-Werror=strict-aliasing]^M
bt_preserve(t, *(pgno_t *)bl-bytes) == RET_ERROR)^M
^^M
...
--- bt_split.So ---^M
cc1: all warnings being treated as errors^M
*** [bt_split.So] Error code 1^M
^M
There may need to be more tailoring someplace before the
powerpc64-xtoolchain-gcc based builds can complete.
Is it known what tailoring is needed?
Also, as is probably expected, my use of TARGET=powerpc TARGET_ARCH=powerpc did
no good for targeting powerpc instead of powerpc64: it produces ELF 64-bit
... for what it does compile.
powerpc64-xtoolchain-gcc (really powerpc64-gcc) will not build on powerpc64: no
self hosting as stands. There is no powerpc-xtoolchain-gcc (yet?).
So it looks like once I know the tailoring required further experiments will
only be building powerpc64 builds from powerpc builds.
Another powerpc64-xtoolchain-gcc point that I noticed was that ${XSTRING} would
not find the strings file to execute. Details follow...
(I use /usr/srcC/ for 11C's /usr/src/ .)
/usr/local/powerpc64-freebsd/bin/ is missing strings but
/usr/srcC/Makefile.inc1 expects it to be there based on CROSS_BUNUTILS_PREFIX
pointing there:
# more /usr/local/share/toolchains/powerpc64-gcc.mk
XCC=/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc
XCXX=/usr/local/bin/powerpc64-portbld-freebsd11.0-g++
XCPP=/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp
CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-freebsd/bin/
X_COMPILER_TYPE=gcc
# ls -FPal /usr/local/powerpc64-freebsd/bin/
total 11400
drwxr-xr-x 2 root wheel 512 Mar 13 12:55 ./
drwxr-xr-x 4 root wheel 512 Mar 13 12:55 ../
-r-xr-xr-x 2 root wheel 989796 Mar 13 12:55 ar*
-r-xr-xr-x 2 root wheel 1394156 Mar 13 12:55 as*
-r-xr-xr-x 4 root wheel 1593868 Mar 13 12:55 ld*
-r-xr-xr-x 4 root wheel 1593868 Mar 13 12:55 ld.bfd*
-r-xr-xr-x 2 root wheel 974520 Mar 13 12:55 nm*
-r-xr-xr-x 2 root wheel 1139108 Mar 13 12:55 objcopy*
-r-xr-xr-x 2 root wheel 1436356 Mar 13 12:55 objdump*
-r-xr-xr-x 2 root wheel 989800 Mar 13 12:55 ranlib*
lrwxr-xr-x 1 root wheel 32 Mar 13 12:55 size@ -
../../bin/powerpc64-freebsd-size
-r-xr-xr-x 2 root wheel 1139112 Mar 13 12:55 strip*
So no strings but...
/usr/srcC/Makefile.inc1 prepends ${CROSS_BINUTILS_PREFIX} to ${STRINGS} to
create XSTRINGS:
XBINUTILS= AS AR LD NM OBJCOPY OBJDUMP RANLIB SIZE STRINGS
.for BINUTIL in ${XBINUTILS}
.if defined(CROSS_BINUTILS_PREFIX)
X${BINUTIL}?= ${CROSS_BINUTILS_PREFIX}${${BINUTIL}}
.else
X${BINUTIL}?= ${${BINUTIL}}
.endif
.endfor
So if a build later uses ${XSTRINGS} it will not find it in the file system for
powerpc64-xtoolchain-gcc.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-12, at 03:13 PM, Mark Millard markmi at dsl-only.net wrote:
Warner wrote:
Is cc1plus the g++ compiler that is installed on your bootstrapped system, or
is it the one that the powerpc64-gcc toolchain built? cc1plus -v will help
determine that. You may have to find it on your system (there’s likely 2) and
pass it the -std=c++11 option to see which of them fail. We may have a leak /
problem with mkdep that your
Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists
Thanks Mark. :( Is cc1plus the g++ compiler that is installed on your bootstrapped system, or is it the one that the powerpc64-gcc toolchain built? cc1plus -v will help determine that. You may have to find it on your system (there’s likely 2) and pass it the -std=c++11 option to see which of them fail. We may have a leak / problem with mkdep that your unique setup is revealing. Warner On Mar 13, 2015, at 5:42 AM, Mark Millard mar...@dsl-only.net wrote: Warner L. wrote about my attempt to use rpc64-xtoolchain-gcc/powerpc64-gcc in a powerpc (non-64) context that has no clang built: Trying WITH_CLANG=t ... So I did... make WITH_CLANG=t CROSS_TOOLCHAIN=powerpc64-gcc toolchain KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc This results in a different failure (cc1plus not understanding the -std=c++11 option that it ends up being given): -- stage 1.2: bootstrap tools -- ... mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\powerpc-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\powerpc-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp ... OMITTING MANY .cpp's ... /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_ostream.cpp cc1plus: error: unrecognized command line option -std=c++11 cc1plus: error: unrecognized command line option -std=c++11 cc1plus: error: unrecognized command line option -std=c++11 ... === Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 01:24 PM, Warner Losh imp at bsdimp.com wrote: Sorry to top post, but try adding WITH_CLANG=t Warner On Mar 13, 2015, at 4:18 AM, Mark Millard mar...@dsl-only.net wrote: Basic context: $ freebsd-version -ku; uname -a 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar 9 22:24:27 PDT 2015 root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc $ svnlite info Path: . Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 380683 Node Kind: directory Schedule: normal Last Changed Author: demon Last Changed Rev: 380683 Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) I bootstrapped into 11.0-CURRENT from 10.1-STABLE but misunderstood UPDATING for the combination of starting from 10.1 on powerpc/powerpc64 and ended up without clang for both powerpc and powerpc64 before I figure that out. While powerpc64-gcc (and so powerpc64-xtoolchain-gcc) fails to build when portmaster'd on powerpc64 it does build on powerpc. So I portmaster'd powerpc64-xtoolchain-gcc in the powerpc (non-64) 11.0-CURRENT context to attempt a cross compile back to powerpc... The problem: (Or is the below attempt a form of abuse of powerpc64-xtoolchain-gcc?) (Remember: no clang exists beforehand.) For... make CROSS_TOOLCHAIN=powerpc64-gcc toolchain KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc or make CROSS_TOOLCHAIN=powerpc64-gcc buildworld buildkernel KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc Either way the result fails to complete by attempting to use clang-tblgen when it does not exist (yet?): ... -- stage 1.2: bootstrap tools -- ... === lib/clang/libllvmx86instprinter (buildincludes) === lib/clang/libllvmx86utils (buildincludes) === lib/clang/include (buildincludes) clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td make[6]: exec(clang-tblgen) failed (No such file or directory) *** Error code 1 Stop. make[6]: stopped in /usr/src/lib/clang/include *** Error code 1 Stop. make[5]: stopped in /usr/src/lib/clang *** Error code 1 Stop. make[4]: stopped in /usr/src/lib *** Error code 1 Stop. make[3]: stopped in /usr/src/lib *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src Even if overall this style of bootstrap should not work it seems odd to me that
Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists
Warner wrote: Is cc1plus the g++ compiler that is installed on your bootstrapped system, or is it the one that the powerpc64-gcc toolchain built? cc1plus -v will help determine that. You may have to find it on your system (there’s likely 2) and pass it the -std=c++11 option to see which of them fail. We may have a leak / problem with mkdep that your unique setup is revealing. The below details indicate that gcc 4.2.1's /usr/libexec/cc1plus was in use when the message about -std=c++11 being unrecognized was generated for make WITH_CLANG=t CROSS_TOOLCHAIN=powerpc64-gcc toolchain KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc. Details... # which cc1plus # So no cc1plus is in my default path: it is being found another way. Ingoring the /usr/src/... and /usr/obj/... paths that have a cc1plus... $ find / -name cc1plus -print /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus ... /usr/libexec/cc1plus ... No others. $ ls -FPal /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 14582156 Mar 12 10:25 /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 15771164 Mar 12 10:25 /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus* $ ls -FPal /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 6541860 Mar 10 23:21 /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 7115952 Mar 10 23:21 /usr/libexec/cc1plus* $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -v ignoring nonexistent directory /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include/c++/4.9.1 ignoring nonexistent directory /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include/c++/4.9.1/powerpc64-portbld-freebsd11.0 ignoring nonexistent directory /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include/c++/4.9.1/backward ignoring nonexistent directory /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/sys-include ignoring nonexistent directory /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerpc64-portbld-freebsd11.0/include #include ... search starts here: #include ... search starts here: /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include-fixed End of search list. ^C $ /usr/libexec/cc1plus -v #include ... search starts here: #include ... search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/backward /usr/include/gcc/4.2 /usr/include End of search list. ^C $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -std=c++11 ^C $ /usr/libexec/cc1plus -std=c++11 cc1plus: error: unrecognized command line option -std=c++11 ^C === Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 02:33 PM, Warner Losh imp at bsdimp.com wrote: Thanks Mark. :( Is cc1plus the g++ compiler that is installed on your bootstrapped system, or is it the one that the powerpc64-gcc toolchain built? cc1plus -v will help determine that. You may have to find it on your system (there’s likely 2) and pass it the -std=c++11 option to see which of them fail. We may have a leak / problem with mkdep that your unique setup is revealing. Warner On Mar 13, 2015, at 5:42 AM, Mark Millard mar...@dsl-only.net wrote: Warner L. wrote about my attempt to use rpc64-xtoolchain-gcc/powerpc64-gcc in a powerpc (non-64) context that has no clang built: Trying WITH_CLANG=t ... So I did... make WITH_CLANG=t CROSS_TOOLCHAIN=powerpc64-gcc toolchain KERNCONF=GENERICvtsc TARGET=powerpc TARGET_ARCH=powerpc This results in a different failure (cc1plus not understanding the -std=c++11 option that it ends up being given): -- stage 1.2: bootstrap tools -- ... mkdep -f .depend -a -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\powerpc-unknown-freebsd11.0\ -DLLVM_HOST_TRIPLE=\powerpc-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp ... OMITTING MANY .cpp's ... /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_ostream.cpp cc1plus: error: unrecognized command line option -std=c++11 cc1plus: error: unrecognized command line option -std=c++11 cc1plus: error:
