From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 13:26:11 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02DE65B2 for ; Mon, 16 Mar 2015 13:26:11 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A6DE3EA9 for ; Mon, 16 Mar 2015 13:26:09 +0000 (UTC) Received: (qmail 2588 invoked from network); 16 Mar 2015 13:26:08 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 16 Mar 2015 13:26:08 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 09:26:08 -0400 (EDT) Received: (qmail 1210 invoked from network); 16 Mar 2015 13:26:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Mar 2015 13:26:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 478EF1C43B7; Mon, 16 Mar 2015 06:26:05 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists From: Mark Millard In-Reply-To: <50E95EBE-B5A0-4C1C-8300-AF4DD773DF9B@bsdimp.com> Date: Mon, 16 Mar 2015 06:26:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29C079E2-51CC-402C-907D-F8BCA6115757@dsl-only.net> References: <81E69CED-2977-4146-A1DA-B199FDAFE146@dsl-only.net> <20150130005619.GA11558@ivaldir.etoilebsd.net> <89F97E94-AB9F-46C0-9AA2-C4D0680D64E7@dsl-only.net> <60F1C8B5-8621-452B-A6A3-DEE4B48B848D@dsl-only.net> <357555BE-7F87-4B25-95BE-43DD33CD8FE2@dsl-only.net> <58E2D419-7DD0-4D93-942C-DA225BDC3455@FreeBSD.org> <50E95EBE-B5A0-4C1C-8300-AF4DD773DF9B@bsdimp.com> To: Warner Losh , Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:26:11 -0000 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=3Dc++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=3D${XCC} CXX=3D${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+=3D CC=3D"${XCC} ${XCFLAGS}" CXX=3D"${XCXX} ${XCFLAGS} = ${XCXXFLAGS}" \ > ... > WMAKE=3D ${WMAKEENV} ${MAKE} ${WORLD_FLAGS} -f Makefile.inc1 = DESTDIR=3D${WORLDTMP} > ... > LIB32WMAKEFLAGS+=3D CC=3D"${XCC} ${LIB32FLAGS}" \ > CXX=3D"${XCXX} ${LIB32FLAGS}" \ > ... > LIB32WMAKE=3D ${LIB32WMAKEENV} ${MAKE} ${LIB32WMAKEFLAGS} \ > ... > LIB32IMAKE=3D ${LIB32WMAKE:NINSTALL=3D*:NDESTDIR=3D*:N_LDSCRIPTROOT=3D= *} \ > ... > KMAKEENV=3D ${WMAKEENV} > KMAKE=3D ${KMAKEENV} ${MAKE} ${.MAKEFLAGS} ${KERNEL_FLAGS} = KERNEL=3D${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=3D${WORLDTMP} \ > MAKEFLAGS=3D"-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS}" \ > MAKEOBJDIRPREFIX=3D${LIB32_OBJTREE} ${MAKE} SSP_CFLAGS=3D = DESTDIR=3D \ > DIRPRFX=3D${_dir}/ -DNO_LINT -DNO_CPU_CFLAGS MK_WARNS=3Dno = MK_CTF=3Dno \ > build-tools > .endfor Also, unfortunately, WITHOUT_CLANG_BOOTSTRAP=3D mixed with WITH_CLANG=3D = 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=3D _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} !=3D "no" || ${MK_CLANG} !=3D "no" > _clang_tblgen=3D \ > lib/clang/libllvmsupport \ > lib/clang/libllvmtablegen \ > usr.bin/clang/tblgen \ > usr.bin/clang/clang-tblgen >=20 > ${_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} "=3D=3D=3D> ${_tool} = (obj,depend,all,install)"; \ > cd ${.CURDIR}/${_tool} && \ > ${MAKE} DIRPRFX=3D${_tool}/ obj && \ > ${MAKE} DIRPRFX=3D${_tool}/ depend && \ > ${MAKE} DIRPRFX=3D${_tool}/ all && \ > ${MAKE} DIRPRFX=3D${_tool}/ = DESTDIR=3D${MAKEOBJDIRPREFIX}/legacy install >=20 > bootstrap-tools: ${_bt}-${_tool} > .endfor I've reverted to trying CROSS_TOOLCHAIN=3Dpowerpc64-gcc using = WITHOUT_CLANG_BOOTSTRAP=3D and WITHOUT_CLANG=3D since even without the = -std=3Dc++11 issue (via my experiment) it tries gcc 4.2.1 for compiling = part of clang during stage 1.2 --and that fails. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 04:51 AM, Warner Losh wrote: > On Mar 16, 2015, at 7:02 PM, Dimitry Andric = wrote: >=20 > On 16 Mar 2015, at 09:02, Mark Millard wrote: >>=20 >> I found why gcc 4.2.1's cc1plus was getting -std=3Dc++11 for the = CROSS_TOOLCHAIN=3Dpowerpc64-gcc compiles that involve WITH_CLANG=3D . = (WITHOUT_CLANG=3D 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...): >>=20 >> # svnlite diff /usr/srcC/lib/clang/clang.build.mk >> Index: /usr/srcC/lib/clang/clang.build.mk >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/srcC/lib/clang/clang.build.mk (revision 279514) >> +++ /usr/srcC/lib/clang/clang.build.mk (working copy) >> @@ -34,8 +34,8 @@ >> CFLAGS+=3D -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"${TARGET_TRIPLE}\" \ >> -DLLVM_HOST_TRIPLE=3D\"${BUILD_TRIPLE}\" \ >> -DDEFAULT_SYSROOT=3D\"${TOOLS_PREFIX}\" >> -CXXFLAGS+=3D -std=3Dc++11 -fno-exceptions -fno-rtti >> -CXXFLAGS.clang+=3D -stdlib=3Dlibc++ >> +CXXFLAGS+=3D -fno-exceptions -fno-rtti >> +CXXFLAGS.clang+=3D -std=3Dc++11 -stdlib=3Dlibc++ >>=20 >> .PATH: ${LLVM_SRCS}/${SRCDIR} >>=20 >> It may be that the "-fno-exceptions -fno-rtti" are also suspect for = being not limited to clang contexts. >=20 > This is incorrect. Clang needs -std=3Dc++11, otherwise it cannot = compile. >=20 > I suspect you also need WITHOUT_CLANG_BOOTSTRAP (and = WITHOUT_GCC_BOOTSTRAP, probably). =46rom earlier debugging, I=E2=80=99m pretty sure that the wrong g++ is = being used in the CROSS_TOOLCHAIN case. I=E2=80=99m in Japan right now = on travel, so I haven=E2=80=99t been able to track it down. = WITHOUT_GCC_BOOTSTRAP should be implied in that case, but if not, that = might explain why... Warner