[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com --- Comment #11 from Mark Millard --- (In reply to HIROKI MORI from comment #10) For head (13) sys/arm/ralink/ is now empty anyway: content removed. There is nothing to build any more (other than for 12 and before). To see that: https://svnweb.freebsd.org/base/head/sys/arm/ralink/ shows it emptied at head -r357395 , something like 3 days ago. Going in a different direction . . . I cross build amd64->armv7,aarch64,powerpc,powerpc64 regularly for head (so 13 currently). No such problems have ever occured. But no "ZRouter build system" is involved. I just use FreeBSD facilities. It appears to me that you were requesting FreeBSD to change in order to allow the alternate build system to work without that other build system being adjusted. However, there is no head (13+) sys/arm/ralink/ content to build now, via any technique. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772
HIROKI MORI changed:
What|Removed |Added
Resolution|Not A Bug |---
Status|Closed |Open
--- Comment #10 from HIROKI MORI ---
I do compile 12-STABLE. This problem dose not occure. But 13-CURRENT still have
this problem. Then I use this patch.
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1092,6 +1092,13 @@ _obj:
@echo "--"
@echo ">>> stage 2.2: rebuilding the object tree"
@echo "--"
+ @mkdir -p ${WORLDTMP}/usr/lib/clang/9.0.1/include/
+ @mkdir -p ${WORLDTMP}/usr/lib/clang/9.0.1/include/cuda_wrappers
+ @mkdir -p ${WORLDTMP}/usr/lib/clang/9.0.1/include/openmp_wrappers
+ @mkdir -p ${WORLDTMP}/usr/lib/clang/9.0.1/include/ppc_wrappers
+ @mkdir -p ${WORLDTMP}/usr/lib/clang/9.0.1/include/sanitizer
+ @mkdir -p ${WORLDTMP}/usr/include/c++/v1/experimental
+ @mkdir -p ${WORLDTMP}/usr/include/c++/v1/ext
${_+_}cd ${.CURDIR}; ${WMAKE} _NO_INCLUDE_COMPILERMK=t obj
_build-tools:
@echo
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 HIROKI MORI changed: What|Removed |Added Resolution|--- |Not A Bug Status|Open|Closed --- Comment #9 from HIROKI MORI --- Sorry. I use normal buildworld then build is complete. I use ZRouter build system. This problem is cause of set option by ZRouter. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 --- Comment #8 from HIROKI MORI --- Created attachment 205908 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=205908=edit This is build log. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772
--- Comment #7 from Dimitry Andric ---
(In reply to HIROKI MORI from comment #6)
> I update 11.3 host os. But still I need this patch.
>
> *** Makefile.inc1.origMon Jul 8 14:27:19 2019
> --- Makefile.inc1 Fri Jul 19 18:05:11 2019
> ***
> *** 1086,1091
> --- 1086,1092
> @echo "--"
> @echo ">>> stage 3: cross tools"
> @echo "--"
> + @mkdir -p
> /usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/freebsd/
> arm.${TARGET_ARCH}/tmp/usr/lib/clang/8.0.1/include/
> @rm -f ${OBJTOP}/toolchain-metadata.mk
> ${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools
> ${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools
> ***
> *** 1103,1108
> --- 1104,
> @echo "--"
> # Special handling for SUBDIR_OVERRIDE in buildworld as they most likely
> need
> # headers from default SUBDIR. Do SUBDIR_OVERRIDE includes last.
> + @mkdir -p ${WORLDTMP}/usr/include/c++/v1/experimental
> + @mkdir -p ${WORLDTMP}/usr/include/c++/v1/ext
> ${_+_}cd ${.CURDIR}; ${WMAKE} SUBDIR_OVERRIDE= SHARED=symlinks \
> MK_INCLUDES=yes includes
> .if !empty(SUBDIR_OVERRIDE) && make(buildworld)
I can only repeat what I mentioned in comment 2, which is that these
directories should be created by mtree, during the earlier stages (e.g. before
"stage 3: cross tools").
If that does not happen for you, can you please check whether your source tree
is cleanly checked out, without any modifications?
If it still fails, can you post a full buildworld log somewhere?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772
--- Comment #6 from HIROKI MORI ---
I update 11.3 host os. But still I need this patch.
*** Makefile.inc1.orig Mon Jul 8 14:27:19 2019
--- Makefile.inc1 Fri Jul 19 18:05:11 2019
***
*** 1086,1091
--- 1086,1092
@echo "--"
@echo ">>> stage 3: cross tools"
@echo "--"
+ @mkdir -p
/usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/freebsd/arm.${TARGET_ARCH}/tmp/usr/lib/clang/8.0.1/include/
@rm -f ${OBJTOP}/toolchain-metadata.mk
${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools
${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools
***
*** 1103,1108
--- 1104,
@echo "--"
# Special handling for SUBDIR_OVERRIDE in buildworld as they most likely need
# headers from default SUBDIR. Do SUBDIR_OVERRIDE includes last.
+ @mkdir -p ${WORLDTMP}/usr/include/c++/v1/experimental
+ @mkdir -p ${WORLDTMP}/usr/include/c++/v1/ext
${_+_}cd ${.CURDIR}; ${WMAKE} SUBDIR_OVERRIDE= SHARED=symlinks \
MK_INCLUDES=yes includes
.if !empty(SUBDIR_OVERRIDE) && make(buildworld)
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 --- Comment #5 from HIROKI MORI --- I use NO_CLEAN again. I think make directory at "stage 2.2: rebuilding the object tree" by lib/clang/8.0.0/include. But I don't found that log. Where define this? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 --- Comment #4 from Dimitry Andric --- (In reply to HIROKI MORI from comment #3) > Thanks for you comment. > > I check my build environment then that set NO_CLEAN. > > I delete this option but I have other error. > > ===> lib/clang/libllvm (all) > llvm-tblgen -gen-attrs -I /usr/home/hiroki/freebsd/contrib/llvm/include -d > llvm > /IR/Attributes.inc.d -o llvm/IR/Attributes.inc > /usr/home/hiroki/freebsd/contrib > /llvm/include/llvm/IR/Attributes.td > llvm-tblgen -gen-intrinsic-enums -I > /usr/home/hiroki/freebsd/contrib/llvm/inclu > de -d llvm/IR/IntrinsicEnums.inc.d -o llvm/IR/IntrinsicEnums.inc > /usr/home/hiro > ki/freebsd/contrib/llvm/include/llvm/IR/Intrinsics.td > llvm-tblgen: Unknown command line argument '-gen-intrinsic-enums'. Try: > 'llvm-t > blgen -help' > llvm-tblgen: Did you mean '-gen-intrinsic'? > *** Error code 1 This can happen when it is running the wrong copy of llvm-tblgen, most likely the one in /usr/bin. It should be running /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/llvm-tblgen instead (this path can be diffent, depending on your setup). If you run "make buildenv" in your top-level source directory, then "which llvm-tblgen", what is the output? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 --- Comment #3 from HIROKI MORI --- Thanks for you comment. I check my build environment then that set NO_CLEAN. I delete this option but I have other error. ===> lib/clang/libllvm (all) llvm-tblgen -gen-attrs -I /usr/home/hiroki/freebsd/contrib/llvm/include -d llvm /IR/Attributes.inc.d -o llvm/IR/Attributes.inc /usr/home/hiroki/freebsd/contrib /llvm/include/llvm/IR/Attributes.td llvm-tblgen -gen-intrinsic-enums -I /usr/home/hiroki/freebsd/contrib/llvm/inclu de -d llvm/IR/IntrinsicEnums.inc.d -o llvm/IR/IntrinsicEnums.inc /usr/home/hiro ki/freebsd/contrib/llvm/include/llvm/IR/Intrinsics.td llvm-tblgen: Unknown command line argument '-gen-intrinsic-enums'. Try: 'llvm-t blgen -help' llvm-tblgen: Did you mean '-gen-intrinsic'? *** Error code 1 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 --- Comment #2 from Dimitry Andric --- (In reply to HIROKI MORI from comment #0) > I build sys/arm/ralink(armv5t) on amd64 host. I have build error on > buildworld after clang update 7.0. > > Now clang is 8.0. I have still error. ... > install: target directory > `/usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/freebsd/arm.arm/tmp/usr/lib/clang/8.0.0/include/' > does not exist ... > install: target directory > `/usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/freebsd/arm.arm/tmp/usr/include/c++/v1/experimental/' > does not exis t In both cases, these directories should have been created with mtree at the end of "stage 1.2: bootstrap tools". In your build log, look for these commands: mtree -deUW -f /usr/src/etc/mtree/BSD.usr.dist -p /usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/freebsd/arm.arm/tmp >/dev/null mtree -deUW -f /usr/src/etc/mtree/BSD.include.dist -p /usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hiroki/freebsd/arm.arm/tmp >/dev/null Those commands should be run just before the next stage, "stage 2.1: cleaning up the object tree" starts. Another thing to check is whether your copies of etc/mtree/BSD.usr.dist and etc/mtree/BSD.include.dist are up to date. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772
--- Comment #1 from HIROKI MORI ---
This is my temporary workaround.
diff --git a/Makefile.inc1 b/Makefile.inc1
index cf166a813d2..0dc58016601 100644
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1084,6 +1084,7 @@ _cross-tools:
@echo "--"
@echo ">>> stage 3: cross tools"
@echo "--"
+ @mkdir -p
/usr/home/hiroki/zobj/usr/home/hiroki/ZRouter/tmp/usr/home/hir
oki/freebsd/arm.arm/tmp/usr/lib/clang/8.0.0/include/
@rm -f ${OBJTOP}/toolchain-metadata.mk
${_+_}cd ${.CURDIR}; ${XMAKE} cross-tools
${_+_}cd ${.CURDIR}; ${XMAKE} kernel-tools
@@ -1101,6 +1102,8 @@ _includes:
@echo "--"
# Special handling for SUBDIR_OVERRIDE in buildworld as they most likely need
# headers from default SUBDIR. Do SUBDIR_OVERRIDE includes last.
+ @mkdir -p ${WORLDTMP}/usr/include/c++/v1/experimental
+ @mkdir -p ${WORLDTMP}/usr/include/c++/v1/ext
${_+_}cd ${.CURDIR}; ${WMAKE} SUBDIR_OVERRIDE= SHARED=symlinks ¥
MK_INCLUDES=yes includes
.if !empty(SUBDIR_OVERRIDE) && make(buildworld)
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 236772] build error on cross compile: '.../c++/v1/experimental/' does not exist
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236772 Kubilay Kocak changed: What|Removed |Added Keywords||needs-qa Assignee|freebsd-...@freebsd.org |toolch...@freebsd.org CC||freebsd-...@freebsd.org Severity|Affects Only Me |Affects Some People Flags||mfc-stable12? Summary|build error on cross|build error on cross |compile |compile: ||'.../c++/v1/experimental/' ||does not exist Status|New |Open -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://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 error: llvm-build: error: invalid native target: 'powerpc64' (not in project)
It appears that I added powerpc64 (and several others) to the devel/llvm* ports version of this patch, but didn't do it for lang/clang*. I'll sync them up. -- Brooks On Tue, Mar 17, 2015 at 08:02:47PM -0700, Mark Millard wrote: patch-utils_llvm-build_llvmbuild_main.py is missing a powerpc64 entry, such as illustrated below. $ svnlite diff /usr/ports/lang/clang36 Index: /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py === --- /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py (revision 381120) +++ /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py (working copy) @@ -3,7 +3,7 @@ --- utils/llvm-build/llvmbuild/main.py.orig +++ utils/llvm-build/llvmbuild/main.py -@@ -633,7 +633,13 @@ +@@ -633,7 +633,14 @@ # We handle a few special cases of target names here for historical # reasons, as these are the names configure currently comes up with. @@ -13,6 +13,7 @@ + 'i386' : 'X86', + 'mips' : 'Mips', + 'powerpc' : 'PowerPC', ++ 'powerpc64' : 'PowerPC', + 'sparc64' : 'Sparc', + 'x86' : 'X86', 'x86_64' : 'X86', === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 11:00 PM, Mark Millard markmi at dsl-only.net wrote: The 2 powerpc (non-64) build attempts for clang 3.6 did not get this problem. So this specific problem is powerpc64 specific. Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/gcc) works fine. (In absence of any c++ port lang/clang36 automatically installed lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 already installed first) still reports an error for not declaring ::sscanf, just like powerpc64 based on gcc5 for bootstrapping did. (This might be llvm/clang making use of only cstdio where an include of stdio.h would be required to be involved in order to guarantee the :: (global) declaration/definition. The way the C++ standard (all vintages) is written gcc 4.8.4 and gcc5 could be this different and both be valid/conforming.) === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:04 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 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
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)
The 2 powerpc (non-64) build attempts for clang 3.6 did not get this problem. So this specific problem is powerpc64 specific. Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/gcc) works fine. (In absence of any c++ port lang/clang36 automatically installed lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 already installed first) still reports an error for not declaring ::sscanf, just like powerpc64 based on gcc5 for bootstrapping did. (This might be llvm/clang making use of only cstdio where an include of stdio.h would be required to be involved in order to guarantee the :: (global) declaration/definition. The way the C++ standard (all vintages) is written gcc 4.8.4 and gcc5 could be this different and both be valid/conforming.) === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:04 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 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
On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 and tried installing lang/gcc491 first then reinstalling lang/clang36 (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string, int, int) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based on adding: #include stdio.h to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on having the only guaranteed-sufficient header explicitly included. We will see what that shows. === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard markmi at dsl-only.net wrote: 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
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared
Adding a #include stdio.h to MSVCToolChain.cpp fixed the specific ::sscanf problem for compiling MSVCToolChain.cpp with gcc5. It also allowed the lang/clang36 build and installation to complete. The official MSVCToolChain.cpp for the port does not directly or indirectly include a header that guarantees to declare/define ::sscanf. But it should. An alternative to the #include is to instead use std::sscanf notation. That will be the next experiment to check if cstdio had been included somewhere or not. It might be that neither header had been included. === Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard markmi at dsl-only.net wrote: Please excuse all the gcc491 references. It is lang/gcc49 and currently that has 4.9.3 . The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc experiments. === Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard markmi at dsl-only.net wrote: On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 and tried installing lang/gcc491 first then reinstalling lang/clang36 (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string, int, int) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based on adding: #include stdio.h to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on having the only guaranteed-sufficient header explicitly included. We will see what that shows. === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard markmi at dsl-only.net wrote: 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,
Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)
patch-utils_llvm-build_llvmbuild_main.py is missing a powerpc64 entry, such as illustrated below. $ svnlite diff /usr/ports/lang/clang36 Index: /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py === --- /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py (revision 381120) +++ /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.py (working copy) @@ -3,7 +3,7 @@ --- utils/llvm-build/llvmbuild/main.py.orig +++ utils/llvm-build/llvmbuild/main.py -@@ -633,7 +633,13 @@ +@@ -633,7 +633,14 @@ # We handle a few special cases of target names here for historical # reasons, as these are the names configure currently comes up with. @@ -13,6 +13,7 @@ + 'i386' : 'X86', + 'mips' : 'Mips', + 'powerpc' : 'PowerPC', ++ 'powerpc64' : 'PowerPC', + 'sparc64' : 'Sparc', + 'x86' : 'X86', 'x86_64' : 'X86', === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 11:00 PM, Mark Millard markmi at dsl-only.net wrote: The 2 powerpc (non-64) build attempts for clang 3.6 did not get this problem. So this specific problem is powerpc64 specific. Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/gcc) works fine. (In absence of any c++ port lang/clang36 automatically installed lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 already installed first) still reports an error for not declaring ::sscanf, just like powerpc64 based on gcc5 for bootstrapping did. (This might be llvm/clang making use of only cstdio where an include of stdio.h would be required to be involved in order to guarantee the :: (global) declaration/definition. The way the C++ standard (all vintages) is written gcc 4.8.4 and gcc5 could be this different and both be valid/conforming.) === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:04 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 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 the final experiment using std::sscanf (so: adding the std) in to the official port's MSVCToolChain.cpp source without adding an explicit include of cstdio. (So also no explicit include of stdio.h, just like the official source file.) It failed: MSVCToolChain.cpp: In member function 'bool clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::string, int, int) const': MSVCToolChain.cpp:215:5: error: 'sscanf' is not a member of 'std' std::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); ^ In other words for the official port's source code (by the above and prior reported experiments): MSVCToolChain.cpp does not directly or indirectly include cstdio. MSVCToolChain.cpp does not directly or indirectly include stdio.h. At that point it is shear luck for there to be any declaration/definition of either ::sscanf or std::sscanf. Apparently gcc 4.8.4 is implicitly providing one someplace for at least ::sscanf. gcc5 and gcc 4.9.3 do not. I do not see any reason to depend on such gcc-version-specific behavior. In my view MSVCToolChain.cpp should have: #include stdio.h added. So the /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/lib/Driver/MSVCToolChain.cpp code would start with something like (once patched?)... (Warning: MSVCToolChain.cpp's initial comment misnames the file name.) //===--- ToolChains.cpp - ToolChain Implementations ---===// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // //===--===// #include ToolChains.h #include clang/Basic/CharInfo.h #include clang/Basic/Version.h #include clang/Driver/Compilation.h #include clang/Driver/Driver.h #include clang/Driver/DriverDiagnostic.h #include clang/Driver/Options.h #include llvm/ADT/StringExtras.h #include llvm/Config/llvm-config.h #include llvm/Option/Arg.h #include llvm/Option/ArgList.h #include llvm/Support/ErrorHandling.h #include llvm/Support/FileSystem.h #include llvm/Support/Process.h #include stdio.h // Include the necessary headers to interface with the Windows registry and // environment. ... === Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 10:57 AM, Mark Millard markmi at dsl-only.net wrote: Adding a #include stdio.h to MSVCToolChain.cpp fixed the specific ::sscanf problem for compiling MSVCToolChain.cpp with gcc5. It also allowed the lang/clang36 build and installation to complete. The official MSVCToolChain.cpp for the port does not directly or indirectly include a header that guarantees to declare/define ::sscanf. But it should. An alternative to the #include is to instead use std::sscanf notation. That will be the next experiment to check if cstdio had been included somewhere or not. It might be that neither header had been included. === Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard markmi at dsl-only.net wrote: Please excuse all the gcc491 references. It is lang/gcc49 and currently that has 4.9.3 . The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc experiments. === Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard markmi at dsl-only.net wrote: On a powerpc (non-64) I did pkg delete's for lang/gcc5 and lang/clang36 and tried installing lang/gcc491 first then reinstalling lang/clang36 (so it would bootstrap via gcc491). The result was the same as for lang/gcc5: llvm[4]: Compiling MSVCToolChain.cpp for Release build MSVCToolChain.cpp: In member function 'bool clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::string, int, int) const': MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared ::sscanf(sdkVersion.c_str(), v%d.%d, major, minor); ^ So gcc 4.8.4 (lang/gcc) is the odd one out here (since it the one of the 3 that does not complain about ::sscanf use). I have another build of lang/gcc5 and then of lang/clang36 going based on adding: #include stdio.h to MSVCToolChain.cpp to see if the problem goes away for gcc5 based on having the only guaranteed-sufficient header explicitly included. We will see what that shows. === Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard markmi at dsl-only.net wrote: 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
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
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:
Re: llvm build error on ppc
On Thu, 13 Nov 2014 20:17:09 +0200 Konstantin Belousov kostik...@gmail.com wrote: Is ppc the only architecture where we do build clang, but with gcc ? Since the failure only occured on ppc/pcc64, and not on e.g. arm. We build with clang on little-endian ARM and don't try to build clang and llvm on big-endian ARM. Andrew ___ 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: llvm build error on ppc
On 13 Nov 2014, at 18:17, Konstantin Belousov kostik...@gmail.com wrote: Is ppc the only architecture where we do build clang, but with gcc ? Since the failure only occured on ppc/pcc64, and not on e.g. arm. It may be the only architecture where we build with gcc by default, but try to install clang as well. PowerPC is very close to working with LLVM, but not quite there yet. I think everything else is either clang-is-default or clang-is-not-even-tried. David ___ 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: Build error
On 29 Aug 2014, at 18:31, Sinha, Prokash psi...@panasas.com wrote:
I was trying to build the latest from the svn trunk - clang/llvm -
langAttrEmitter.cpp:994:29: error: 'SimpleArgument' does not refer to a value
Ptr = llvm::make_uniqueSimpleArgument(Arg, Attr, int);
^
ClangAttrEmitter.cpp:216:9: note: declared here
class SimpleArgument : public Argument {
^
ClangAttrEmitter.cpp:994:45: warning: expression result unused
[-Wunused-value]
Ptr = llvm::make_uniqueSimpleArgument(Arg, Attr, int);
^~~
ClangAttrEmitter.cpp:994:50: warning: expression result unused
[-Wunused-value]
Ptr = llvm::make_uniqueSimpleArgument(Arg, Attr, int);
^~~~
ClangAttrEmitter.cpp:996:17: error: no member named 'make_unique' in
namespace 'llvm'
Ptr = llvm::make_uniqueStringArgument(Arg, Attr);
~~^
Any suggestion?
Completely clean out /usr/obj, and try again.
-Dimitry
signature.asc
Description: Message signed with OpenPGP using GPGMail
