powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string,int, int) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being likely to be powerpc64 specific would be my guess. May be that it bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=clang-cpp #CC=clang #CXX=clang++ WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === 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
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
Which compiler are you building with? Just using the normal lang/gcc works for me without issue doing make install in lang/clang36. Are you sure you don't have any local diffs or stale files? -Nathan On 03/16/15 17:18, Mark Millard wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string,int, int) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being likely to be powerpc64 specific would be my guess. May be that it bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=clang-cpp #CC=clang #CXX=clang++ WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === 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
powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)
Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error report was after it reported entering the directory: /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/lib/Driver/ The report was: llvm-build: error: invalid native target: 'powerpc64' (not in project) I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 likely does. I've not yet tried from a powerpc (non-64) FreeBSD build. I'll note that with top -PaSCHopid I watched it compile the PowerPc code generator software: it shoudl be able to handle PowerPCs fine. My guess is a conversion of naming conventions is required someplace: FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) This likely would matter for little endian naming as well (ppc64le on the clang end of things I expect). Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=clang-cpp #CC=clang #CXX=clang++ WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === 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
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
I tried portmaster -tDK --no-confirm lang/clang36 on a powerpc (non-64): $ freebsd-version -ku ; uname -ap 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 powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no other non-built-in-world compilers ever having been installed before. No clang of any kind to start with. Just gcc 4.2.1. No changes to lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::string, int, int) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); ^ Like before when I had installed gcc5 it had no troubles installing and I made no changes. I have another build test running where only built-in-world compilers existed (gcc 4.2.1 and clang 3.4.1). For this context portmaster -tDK --no-confirm lang/clang36 initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to provide itself with a compiler to bootstrap with. We will see how that one does. It takes longer since 2 compilers are being installed. (I started this one first but it is not done yet.) === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard markmi at dsl-only.net wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string,int, int) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being likely to be powerpc64 specific would be my guess. May be that it bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: brooks Last Changed Rev: 380295 Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015) It used gcc5 to bootstrap as there was no clang present and that is the only gcc port installed: # svnlite info /usr/ports/lang/gcc5 Path: lang/gcc5 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5 Relative URL: ^/head/lang/gcc5 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 381120 Node Kind: directory Schedule: normal Last Changed Author: gerald Last Changed Rev: 380943 Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015) # more /etc/make.conf #CPP=clang-cpp #CC=clang #CXX=clang++ WRKDIRPREFIX=/usr/obj/portswork #WITH_DEBUG= MALLOC_PRODUCTION= === 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
powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload
Basic context (more is listed later):
# freebsd-version -ku ; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11
19:23:14 PDT 2015
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG
powerpc powerpc64
With my limping-along powerpc64-xtoolchain-gcc being used on a powerpc64 with
CROSS_TOOLCHAIN=powerpc64-gcc I recently got it as far as...
The reported ambiguous overload...
In file included from /usr/obj/usr/srcC/tmp/usr/include/atf-c++.hpp:29:0,^M
from /usr/srcC/lib/libnv/tests/dnv_tests.cc:30:^M
/usr/srcC/lib/libnv/tests/dnv_tests.cc: In member function 'virtual void
{anonymous}::atfu_tc_dnvlist_take_nvlist__empty::body() const':^M
/usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload for
'operator' (operand types are 'std::__1::basic_ostreamchar' and
'std::nullptr_t')^M
ATF_REQUIRE_EQ(actual_val, NULL);^M
^^M
/usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: note: candidates are:^M
In file included from /usr/obj/usr/srcC/tmp/usr/include/c++/v1/sstream:174:0,^M
from /usr/obj/usr/srcC/tmp/usr/include/atf-c++/macros.hpp:29,^M
from /usr/obj/usr/srcC/tmp/usr/include/atf-c++.hpp:29,^M
from /usr/srcC/lib/libnv/tests/dnv_tests.cc:30:^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:320:1: note:
std::__1::basic_ostream_CharT, _Traits std::__1::basic_ostream_CharT,
_Traits::operator(std::__1::basic_ostream_CharT, _Traits (
*)(std::__1::basic_ostream_CharT, _Traits)) [with _CharT = char; _Traits =
std::__1::char_traitschar]^M
basic_ostream_CharT, _Traits::operator(basic_ostream
(*__pf)(basic_ostream))^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:328:1: note:
std::__1::basic_ostream_CharT, _Traits std::__1::basic_ostream_CharT,
_Traits::operator(std::__1::basic_ios_CharT, _Traits (*)(s
td::__1::basic_ios_CharT, _Traits)) [with _CharT = char; _Traits =
std::__1::char_traitschar]^M
basic_ostream_CharT, _Traits::operator(basic_ioschar_type, traits_type^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:338:1: note:
std::__1::basic_ostream_CharT, _Traits std::__1::basic_ostream_CharT,
_Traits::operator(std::__1::ios_base (*)(std::__1::ios_base
)) [with _CharT = char; _Traits = std::__1::char_traitschar]^M
basic_ostream_CharT, _Traits::operator(ios_base (*__pf)(ios_base))^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:398:1: note:
std::__1::basic_ostream_CharT, _Traits std::__1::basic_ostream_CharT,
_Traits::operator(bool) [with _CharT = char; _Traits = std::_
_1::char_traitschar]^M
basic_ostream_CharT, _Traits::operator(bool __n)^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:718:1: note:
std::__1::basic_ostream_CharT, _Traits std::__1::basic_ostream_CharT,
_Traits::operator(const void*) [with _CharT = char; _Traits =
std::__1::char_traitschar]^M
basic_ostream_CharT, _Traits::operator(const void* __n)^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:346:1: note:
std::__1::basic_ostream_CharT, _Traits std::__1::basic_ostream_CharT,
_Traits::operator(std::__1::basic_streambuf_CharT, _Traits*
) [with _CharT = char; _Traits = std::__1::char_traitschar]^M
basic_ostream_CharT, _Traits::operator(basic_streambufchar_type,
traits_type* __sb)^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:907:1: note:
std::__1::basic_ostreamchar, _Traits
std::__1::operator(std::__1::basic_ostreamchar, _Traits, const unsigned
char*) [with _Traits
= std::__1::char_traitschar]^M
operator(basic_ostreamchar, _Traits __os, const unsigned char* __str)^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:899:1: note:
std::__1::basic_ostreamchar, _Traits
std::__1::operator(std::__1::basic_ostreamchar, _Traits, const signed
char*) [with _Traits =
std::__1::char_traitschar]^M
operator(basic_ostreamchar, _Traits __os, const signed char* __str)^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:892:1: note:
std::__1::basic_ostreamchar, _Traits
std::__1::operator(std::__1::basic_ostreamchar, _Traits, const char*)
[with _Traits = std::__
1::char_traitschar]^M
operator(basic_ostreamchar, _Traits __os, const char* __str)^M
^^M
/usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:846:1: note:
std::__1::basic_ostream_CharT, _Traits
std::__1::operator(std::__1::basic_ostream_CharT, _Traits, const char*)
[with _CharT = char
; _Traits = std::__1::char_traitschar]^M
operator(basic_ostream_CharT, _Traits __os, const char* __strn)^M
^^M
Other context details:
make CROSS_TOOLCHAIN=powerpc64-gcc \
WITHOUT_CLANG_BOOTSTRAP= \
WITHOUT_CLANG_IS_CC= WITHOUT_CLANG= WITHOUT_CLANG_EXTRAS= WITHOUT_CLANG_FULL= \
WITHOUT_LLDB= \
WITHOUT_GCC_BOOTSTRAP= WITHOUT_GCC= \
WITHOUT_BINUTILS_BOOTSTRAP= WITHOUT_BINUTILS=
buildworld buildkernel KERNCONF=GENERIC64vtsc-NODEBUG \
TARGET=powerpc TARGET_ARCH=powerpc64
(Yes I was being paranoid about various automatic settings that are based on
other ones. Any form
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: powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload
On 2015-Mar-16, at 07:41 AM, Ryan Stone ryst...@gmail.com wrote: This should have been fixed in r276760: https://svnweb.freebsd.org/changeset/base/279760 Ahh. Thanks. I'm at -r279514 because when I tried to get from there to -r279813 for my powerpc64/powerpc context it was a disaster. Luckily I had a duplicate SSD of the before-attempt status to restore with. The problem was that as soon as it had done /usr/libexec/ld-elf.so.1 - /libexec/ld-elf.so.1 then all attempts t run new problem got Bus error (core dumped) and *** Error code 138, stopping the installworld and making booting fail. I generally jump from snapshot to snapshot. I only recently started experimenting with 11.0-CURRENT. (Nathan W. had asked that I try something there and I decided it was time to see about starting to experiment.) I've svnlite update'd the specific 2 files and have restarted the build. === 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
Re: powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload
This should have been fixed in r276760: https://svnweb.freebsd.org/changeset/base/279760 ___ 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
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
The last powerpc (non-64) build test to complete ran where only built-in-world compilers originally existed (gcc 4.2.1 and clang 3.4.1 this time. For this context portmaster -tDK --no-confirm lang/clang36 initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to provide itself with a compiler to bootstrap with. The result: no failures and a full clang 3.6 installation by being bootstrapped via gcc 4.8.4. So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 specifically... Here is what I would guess is going on: llvm's source code sometimes uses stdio.h and other times cstdio. (I did find with grep's.) One would have to trace all the headers actually included for MSVCToolChain.cpp, directly or indirectly, and see which one(s) are involved. But for ::sscanf notation they should be explicitly including stdio.h somewhere for that context. (Having cstdio in addition is fine.) The rule is as follows, using an example. The C++ standard (various vintages) has at least one vintage that uses cstdlib vs. stdlib.h as an example for... The header cstdlib assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header stdlib.h assuredly provides the same declarations and definitions within the global namespace, much as in the C Standard. It may also provide these names within the namespace std. So... cstdio only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); stdlib.h only guarantees: int ::sscanf( const char* buffer, const char* format, ... ); But either file is allowed to (not required to) also declare/define the other alternative as well. In other words: For portable code the burden of selecting appropriately is on the folks including the headers. Otherwise just because it works in one valid toolchain does not mean it is guaranteed to work in another valid one. gcc5 may well provide fewer of the optional declarations/definitions for some headers. === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard markmi at dsl-only.net wrote: I tried portmaster -tDK --no-confirm lang/clang36 on a powerpc (non-64): $ freebsd-version -ku ; uname -ap 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 powerpc Again it used gcc5 to bootstrap, my having installed gcc5 recently, no other non-built-in-world compilers ever having been installed before. No clang of any kind to start with. Just gcc 4.2.1. No changes to lang/clang36. Just: portmaster -tDK --no-confirm lang/clang36 Again it had the same MSVCToolChain.cpp problem: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::string, int, int) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); ^ Like before when I had installed gcc5 it had no troubles installing and I made no changes. I have another build test running where only built-in-world compilers existed (gcc 4.2.1 and clang 3.4.1). For this context portmaster -tDK --no-confirm lang/clang36 initiated installing lang/gcc (i.e., 4.8.4 at this point) in order to provide itself with a compiler to bootstrap with. We will see how that one does. It takes longer since 2 compilers are being installed. (I started this one first but it is not done yet.) === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, Mark Millard markmi at dsl-only.net wrote: Basic context (more context details listed later): # freebsd-version -ku; uname -ap 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc powerpc64 The problem: portmaster -tDK --no-confirm lang/clang36 is how I started the build. The error reported was for in MSVCToolChain.cpp's member function: bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string,int, int) const The report was: MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being likely to be powerpc64 specific would be my guess. May be that it bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build. Context details: # svnlite info /usr/ports/lang/clang36 Path: lang/clang36 Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36 Relative URL: ^/head/lang/clang36 Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision:
