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. Note that the above change seems to allow things to run past the point of the problem but I do not know if running the gcc 4.2.1's cc1plus was really the right thing for whatever was being done when it was reporting the not-recognized errors. That could be a different defect. The build attempt does eventually use the cross compiler despite the initial gcc 4.2.1 cc1plus use. A separate issue is that building clang requires libstdc++ or libc++ (such as having use of the typetraits header) and powerpc64-xtoolchain-gcc does not include such a library. So even after the above change the builds fail whenever WITH_CLANG= is involved. An "out of the box" powerpc64-xtoolchain-gcc on powerpc64 is potentially good for an incomplete FreeBSD 11.0-CURRENT build that excludes clang. On powerpc (non-64) powerpc64-gcc got errors on assembler notation (when clang was excluded so it could otherwise run). I'm still checking powerpc64-gcc on powerpc64 with clang excluded. [In order to have powerpc64-gcc and powerpc64-xtoolchain-gcc installed on powerpc64 I copied the 4 /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/ files that had wrong names to the also have copies under the names it was trying to use. I also copied /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/gcov to /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/powerpc64-portbld-freebsd11.0-gcov where it had been missing. portmaster -DKC devel/powerpc64-xtoolchain-gcc was then able to continue from there and installed powerpc64-gcc and 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 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: 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 clang-tblgen use was attempted before it was built. >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" > > _______________________________________________ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"