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 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
_______________________________________________
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"
