From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 15 00:38:55 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A4F1B8F for ; Sun, 15 Mar 2015 00:38:55 +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 3FAE77E2 for ; Sun, 15 Mar 2015 00:38:54 +0000 (UTC) Received: (qmail 24288 invoked from network); 15 Mar 2015 00:38:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 15 Mar 2015 00:38:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 14 Mar 2015 20:38:52 -0400 (EDT) Received: (qmail 1473 invoked from network); 15 Mar 2015 00:38:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Mar 2015 00:38:50 -0000 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 6E5411C405E; Sat, 14 Mar 2015 17:38:44 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h's IntrusiveRefCntPtr and its use violates C++ privacy rules Message-Id: <8CFA382E-85D3-4A02-A448-3284C827DC29@dsl-only.net> Date: Sat, 14 Mar 2015 17:38:48 -0700 To: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) 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: Sun, 15 Mar 2015 00:38:55 -0000 When trying to build the 11.0-CURRENT clang 3.5 on powerpc64 I ran into = a violation of C++ accessibility rules (for private) that stopped the = compile. contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h has... template class IntrusiveRefCntPtr { T* Obj; public: ... template IntrusiveRefCntPtr(IntrusiveRefCntPtr&& S) : Obj(S.get()) { S.Obj =3D 0; } ... } To first illustrate a (partial) but-simpler-to-follow example use that = would show the problem: using Ta =3D ...; using Tb =3D ...; // Note that private members of IntrusiveRefCntPtr // are not (should not be) accessible to // IntrusiveRefCntPtr methods (and vice-versa). IntrusiveRefCntPtr a{} IntrusiveRefCntPtr b{a}; // We then would have a usage where an example of: IntrusiveRefCntPtr::IntrusiveRefCntPtr is then trying to access an example of IntrusiveRefCntPtr's Obj private member. It would take a friend relationship to be established to allow the = cross-type access to Obj. The code in = contrib/llvm/tools/clang/lib/Frontend/ChainedIncludesSource.cpp has such = a use and so makes an instance of the violation of the language rules in = the actual code. The function clang::createChainedIncludesSourceIt uses classes...=20 class ChainedIncludesSource : public ExternalSemaSource where... class ExternalSemaSource : public ExternalASTSource where... class ExternalASTSource : public RefCountedBase where... template class RefCountedBase; and it uses both of the following types... IntrusiveRefCntPtr and... IntrusiveRefCntPtr In fact IntrusiveRefCntPtr is the = return-expresison type for the following routine that has return type = IntrusiveRefCntPtr... IntrusiveRefCntPtr = clang::createChainedIncludesSource( CompilerInstance &CI, IntrusiveRefCntPtr = &Reader) { ... IntrusiveRefCntPtr source(new = ChainedIncludesSource()); ... return source; } =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 06:07:26 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 E1A03E9A for ; Mon, 16 Mar 2015 06:07:26 +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 98F6C805 for ; Mon, 16 Mar 2015 06:07:25 +0000 (UTC) Received: (qmail 17193 invoked from network); 16 Mar 2015 06:07:19 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 16 Mar 2015 06:07:19 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 02:07:19 -0400 (EDT) Received: (qmail 13287 invoked from network); 16 Mar 2015 06:07:18 -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 06:07:18 -0000 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 8ED2C1C43A6; Sun, 15 Mar 2015 23:07:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc (non-64) using CROSS_TOOLCHAIN=powerpc64-gcc fails: .TOC.@tocbase notation not recognized From: Mark Millard In-Reply-To: <9855CD5C-9086-412F-AD5B-370EAC58D4EC@dsl-only.net> Date: Sun, 15 Mar 2015 23:07:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1D5C9892-8660-4370-BD29-AD2037E99C73@dsl-only.net> References: <9855CD5C-9086-412F-AD5B-370EAC58D4EC@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) 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 06:07:27 -0000 In reading my note: Be warned that something is replacing the at-signs = in the assembler notation with "at" with an underscore before and after. = The original I sent was not like that. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-13, at 10:43 PM, Mark Millard = wrote: Basic execution context: > # 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 Attmpted: make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc buildworld = buildkernel KERNCONF=3DGENERIC64vtsc-NODEBUG TARGET=3DpowerPC = TARGET_ARCH=3Dpowerpc64 > # more /etc/src.conf=20 > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > WITHOUT_CLANG=3D > NO_WERROR=3D Note that CROSS_TOOLCHAIN=3Dpowerpc64-gcc means the produced files are = ELF 64-bit (even if TARGET_ARCH and/or KERNCONF indicates powerpc). I = remembered to type GENERIC64vtsc to match. :) I had to explicitly supply = TARGET_ARCH=3Dpowerpc64 or it would pick TARGET_ARCH=3Dpowerpc instead. WITHOUT_CLANG=3D avoids various build issues, including lack of any = sufficient c++11 library for building clang. NO_WERROR=3D avoids stopping for warnings that would prevent the build. = I did not figure out any finer grain level of control for a basic = experiment. The problem (something needed else to control configuration?): ... > --- crti.o ---^M > gcc -O2 -pipe -I/usr/srcC/lib/csu/powerpc64/../common = -I/usr/srcC/lib/csu/powerpc64/../../libc/include -mlongcall -std=3Dgnu99 = -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type = -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter = -Wcast-align -Wchar-subscripts -Winline -Wnested-externs = -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c = /usr/srcC/lib/csu/powerpc64/crti.S^M > ... > /usr/srcC/lib/csu/powerpc64/crti.S: Assembler messages:^M > /usr/srcC/lib/csu/powerpc64/crti.S:35: Error: junk at end of line, = first unrecognized character is `@'^M > /usr/srcC/lib/csu/powerpc64/crti.S:51: Error: junk at end of line, = first unrecognized character is `@'^M > *** [crti.o] Error code 1^M > ^M (gcc: so the old compiler is used for assembly of sources.) The lines of crti.S in question are: > .quad .L._init,.TOC.@tocbase,0 > ... > .quad .L._fini,.TOC.@tocbase,0 The crti.S code (starting at the #include) is: > #include > __FBSDID("$FreeBSD: head/lib/csu/powerpc64/crti.S 218824 2011-02-18 = 21:44:53Z nwhitehorn $"); >=20 > .section .init,"ax",@progbits > .align 2 > .globl _init > .section ".opd","aw" > .align 3 > _init: > .quad .L._init,.TOC.@tocbase,0 > .previous > .type _init,@function >=20 > .align 4 > .L._init: > stdu 1,-48(1) > mflr 0 > std 0,64(1) >=20 > .section .fini,"ax",@progbits > .align 2 > .globl _fini > .section ".opd","aw" > .align 3 > _fini: > .quad .L._fini,.TOC.@tocbase,0 > .previous > .type _fini,@function >=20 > .align 4 > .L._fini: > stdu 1,-48(1) > mflr 0 > std 0,64(1) >=20 > .section .note.GNU-stack,"",%progbits Other context details: > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D > # svnlite info > Path: . > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 08:02:15 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1CBABB4 for ; Mon, 16 Mar 2015 08:02:15 +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 8247636D for ; Mon, 16 Mar 2015 08:02:14 +0000 (UTC) Received: (qmail 6660 invoked from network); 16 Mar 2015 08:02:13 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Mar 2015 08:02:13 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 04:02:13 -0400 (EDT) Received: (qmail 22103 invoked from network); 16 Mar 2015 08:02:12 -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 08:02:12 -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 6CF1B1C43A6; Mon, 16 Mar 2015 01:02:11 -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: <357555BE-7F87-4B25-95BE-43DD33CD8FE2@dsl-only.net> Date: Mon, 16 Mar 2015 01:02:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Warner Losh 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 08:02:15 -0000 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...): # 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} It may be that the "-fno-exceptions -fno-rtti" are also suspect for = being not limited to clang contexts. Note that the above change seems to allow things to run past the point = of the problem but I do not know if running the gcc 4.2.1's cc1plus was = really the right thing for whatever was being done when it was reporting = the not-recognized errors. That could be a different defect. The build attempt does eventually use the cross compiler despite the = initial gcc 4.2.1 cc1plus use. A separate issue is that building clang requires libstdc++ or libc++ = (such as having use of the typetraits header) and = powerpc64-xtoolchain-gcc does not include such a library. So even after = the above change the builds fail whenever WITH_CLANG=3D is involved. An = "out of the box" powerpc64-xtoolchain-gcc on powerpc64 is potentially = good for an incomplete FreeBSD 11.0-CURRENT build that excludes clang. On powerpc (non-64) powerpc64-gcc got errors on assembler notation (when = clang was excluded so it could otherwise run). I'm still checking powerpc64-gcc on powerpc64 with clang excluded. [In order to have powerpc64-gcc and powerpc64-xtoolchain-gcc installed = on powerpc64 I copied the 4 = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/= man1/ files that had wrong names to the also have copies under the names = it was trying to use. I also copied = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/build-gcc/gcc/gcov = to = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/= powerpc64-portbld-freebsd11.0-gcov where it had been missing. portmaster = -DKC devel/powerpc64-xtoolchain-gcc was then able to continue from there = and installed powerpc64-gcc and powerpc64-xtoolchain-gcc.] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 03:13 PM, Mark Millard = wrote: Warner wrote: > Is cc1plus the g++ compiler that is installed on your bootstrapped = system, or is it the one that the powerpc64-gcc toolchain built? cc1plus = -v will help determine that. You may have to find it on your system = (there=E2=80=99s likely 2) and pass it the -std=3Dc++11 option to see = which of them fail. We may have a leak / problem with mkdep that your = unique setup is revealing. The below details indicate that gcc 4.2.1's /usr/libexec/cc1plus was in = use when the message about -std=3Dc++11 being unrecognized was generated = for "make WITH_CLANG=3Dt CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc". Details... # which cc1plus # So no cc1plus is in my default path: it is being found another way. Ingoring the /usr/src/... and /usr/obj/... paths that have a cc1plus... $ find / -name cc1plus -print /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus ... /usr/libexec/cc1plus ... No others. $ ls -FPal = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 14582156 Mar 12 10:25 = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 15771164 Mar 12 10:25 = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus* $ ls -FPal /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 6541860 Mar 10 23:21 /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 7115952 Mar 10 23:21 /usr/libexec/cc1plus* $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -v ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1/powerpc64-portbld-freebsd11.0" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1/backward" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/sys-include" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include-fixed End of search list. ^C $ /usr/libexec/cc1plus -v #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/backward /usr/include/gcc/4.2 /usr/include End of search list. ^C $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus = -std=3Dc++11 ^C $ /usr/libexec/cc1plus -std=3Dc++11 cc1plus: error: unrecognized command line option "-std=3Dc++11" ^C =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 02:33 PM, Warner Losh wrote: Thanks Mark. :( Is cc1plus the g++ compiler that is installed on your bootstrapped = system, or is it the one that the powerpc64-gcc toolchain built? cc1plus = -v will help determine that. You may have to find it on your system = (there=E2=80=99s likely 2) and pass it the -std=3Dc++11 option to see = which of them fail. We may have a leak / problem with mkdep that your = unique setup is revealing. Warner > On Mar 13, 2015, at 5:42 AM, Mark Millard wrote: >=20 > Warner L. wrote about my attempt to use = rpc64-xtoolchain-gcc/powerpc64-gcc in a powerpc (non-64) context that = has no clang built: >=20 >> Trying WITH_CLANG=3Dt ... >=20 > So I did... >=20 > make WITH_CLANG=3Dt CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >=20 > This results in a different failure (cc1plus not understanding the = -std=3Dc++11 option that it ends up being given): >=20 > -------------------------------------------------------------- >>>> stage 1.2: bootstrap tools > -------------------------------------------------------------- > ... > mkdep -f .depend -a = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support = -I. = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -std=3Dc++11 = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp > ... ... = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_os= tream.cpp > cc1plus: error: unrecognized command line option "-std=3Dc++11" > cc1plus: error: unrecognized command line option "-std=3Dc++11" > cc1plus: error: unrecognized command line option "-std=3Dc++11" > ... >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-12, at 01:24 PM, Warner Losh wrote: >=20 > Sorry to top post, but try adding WITH_CLANG=3Dt >=20 > Warner >=20 >> On Mar 13, 2015, at 4:18 AM, Mark Millard = wrote: >>=20 >> Basic context: >>=20 >> $ freebsd-version -ku; uname -a >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon = Mar 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc >> $ svnlite info >> Path: . >> Working Copy Root Path: /usr/ports >> URL: https://svn0.us-west.freebsd.org/ports/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 380683 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: demon >> Last Changed Rev: 380683 >> Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >>=20 >> I bootstrapped into 11.0-CURRENT from 10.1-STABLE but misunderstood = UPDATING for the combination of starting from 10.1 on powerpc/powerpc64 = and ended up without clang for both powerpc and powerpc64 before I = figure that out. >>=20 >> While powerpc64-gcc (and so powerpc64-xtoolchain-gcc) fails to build = when portmaster'd on powerpc64 it does build on powerpc. >>=20 >> So I portmaster'd powerpc64-xtoolchain-gcc in the powerpc (non-64) = 11.0-CURRENT context to attempt a "cross" compile back to powerpc... >>=20 >>=20 >>=20 >> The problem: >> (Or is the below attempt a form of abuse of = powerpc64-xtoolchain-gcc?) >> (Remember: no clang exists beforehand.) >>=20 >> For... >>=20 >> make CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain KERNCONF=3DGENERICvtsc = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>=20 >> or >>=20 >> make CROSS_TOOLCHAIN=3Dpowerpc64-gcc buildworld buildkernel = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>=20 >> Either way the result fails to complete by attempting to use = clang-tblgen when it does not exist (yet?): >>=20 >>> ... >>> -------------------------------------------------------------- >>>>>> stage 1.2: bootstrap tools >>> -------------------------------------------------------------- >>> ... >>> =3D=3D=3D> lib/clang/libllvmx86instprinter (buildincludes) >>> =3D=3D=3D> lib/clang/libllvmx86utils (buildincludes) >>> =3D=3D=3D> lib/clang/include (buildincludes) >>> clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h = /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang= /Basic/arm_neon.td >>> make[6]: exec(clang-tblgen) failed (No such file or directory) >>> *** Error code 1 >>>=20 >>> Stop. >>> make[6]: stopped in /usr/src/lib/clang/include >>> *** Error code 1 >>>=20 >>> Stop. >>> make[5]: stopped in /usr/src/lib/clang >>> *** Error code 1 >>>=20 >>> Stop. >>> make[4]: stopped in /usr/src/lib >>> *** Error code 1 >>>=20 >>> Stop. >>> make[3]: stopped in /usr/src/lib >>> *** Error code 1 >>>=20 >>> Stop. >>> make[2]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/src >>=20 >>=20 >>=20 >> Even if overall this style of bootstrap should not work it seems odd = to me that clang-tblgen use was attempted before it was built. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 10:02:27 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 62FBB48D; Mon, 16 Mar 2015 10:02:27 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 16E8E22E; Mon, 16 Mar 2015 10:02:26 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::5dde:9dd3:e3f7:7226] (unknown [IPv6:2001:7b8:3a7:0:5dde:9dd3:e3f7:7226]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DFC595C47; Mon, 16 Mar 2015 11:02:14 +0100 (CET) Subject: Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_17593A11-0470-4458-AD4D-83699C7AD831"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Dimitry Andric In-Reply-To: Date: Mon, 16 Mar 2015 11:02:09 +0100 Message-Id: <58E2D419-7DD0-4D93-942C-DA225BDC3455@FreeBSD.org> 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> To: Mark Millard 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 10:02:27 -0000 --Apple-Mail=_17593A11-0470-4458-AD4D-83699C7AD831 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. This is incorrect. Clang needs -std=3Dc++11, otherwise it cannot = compile. I suspect you also need WITHOUT_CLANG_BOOTSTRAP (and = WITHOUT_GCC_BOOTSTRAP, probably). -Dimitry --Apple-Mail=_17593A11-0470-4458-AD4D-83699C7AD831 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlUGqiUACgkQsF6jCi4glqPU9QCfVrQ0FCVkgxUnw9gbQcTp7gCE YhkAoKKsKoRh5Fy55v7wYM97lm83uHU4 =lUZt -----END PGP SIGNATURE----- --Apple-Mail=_17593A11-0470-4458-AD4D-83699C7AD831-- From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 11:52:01 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B93C3BA3 for ; Mon, 16 Mar 2015 11:52:01 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7F3C2176 for ; Mon, 16 Mar 2015 11:52:01 +0000 (UTC) Received: by pdbop1 with SMTP id op1so56395689pdb.2 for ; Mon, 16 Mar 2015 04:51:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=M4+VRtojWiiWKHIak4iuUDu9oYnc/5i3vqBIGyD9u3w=; b=OPtUvrgTcpHKN1EXucFHZt3AVbzrVp10VFMrQze8CLOSIvghgYeydPx7ioaV0ySX8L zMXHN13jSHe5ghXJSHUza23+zKOvCSGYwW0ShfzbHaEFXTmv6zsG4e6n25tKe/yzZK1q 0CNIWLNyiTMgURJjVTEPpgd39OBINKpz8VmKy9BBjBYzchCMBrl1nmugFYW7myaPV8Xa Ap3iSktxrX4wwkq2XX29urJjSoiUDiPD/6Obo0p0MCfLQ7h34Bih0uc4BU/jxjtK0iM6 VjgS6kUUusQqh2qH4a0eUQKEjC11TR4AAqWJ6dVR7ZTtJmlp5EB03AqF/REfQNrXBLQ6 YyLQ== X-Gm-Message-State: ALoCoQmz9FG0/icNsvyfUC7IlTaIsWNbebGvNIlAjuIYJvvHsOYEOzjSaq4ConOZsy2n9HRUXbip X-Received: by 10.66.147.169 with SMTP id tl9mr134855874pab.63.1426506715257; Mon, 16 Mar 2015 04:51:55 -0700 (PDT) Received: from [10.216.193.143] ([210.160.37.26]) by mx.google.com with ESMTPSA id oj16sm7021164pdb.77.2015.03.16.04.51.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 04:51:54 -0700 (PDT) Sender: Warner Losh Subject: Re: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E9685780-00DD-4E91-BDB8-9DF080D3B207"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: <58E2D419-7DD0-4D93-942C-DA225BDC3455@FreeBSD.org> Date: Mon, 16 Mar 2015 20:51:51 +0900 Message-Id: <50E95EBE-B5A0-4C1C-8300-AF4DD773DF9B@bsdimp.com> 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> To: Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML , Mark Millard 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 11:52:01 -0000 --Apple-Mail=_E9685780-00DD-4E91-BDB8-9DF080D3B207 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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 --Apple-Mail=_E9685780-00DD-4E91-BDB8-9DF080D3B207 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVBsPXAAoJEGwc0Sh9sBEADmoQAMaWtT8Uxbsx+hTHDDagIvsT 6hP7x8f6BViInITAXzQqIVMQX9hocK8xXWymjn/g0KtUiYFKRhF/6iw3qSlV2LoQ 8n88nnoM+hFE3EMxM+nYOaElCOXPezbxRtyY5xRT5mjW6b+aKWjq4bBhKKBJhHB8 qSkMcMHEWa2w9igBXofLaXEIyy6h4zO9bbZMv7qf6QLwWuU1GQdIkYKp3H0/9/e5 NG+xnPhzsvPsJBh2WjoHhF1zt+bOopD35byVq3tQrksecViW+k6flxecD4XLOtty 7DFWUGXGs5KIIbc57aHCHSUh8xxrn9WJ0msN68WcZGJfamIA8nFOjKIg2Cnkkpk7 wUIku8mG8iRXtkMrNS3MyEO2kRPGILbo6I+cRr+TA13ce/4gt/WSZe8e0S6gC1sw bKKtotVR/zwp5k8AP14YnE6EraUEj3mII6zZkfo0jZlEULiyAXVmGE6aapmQNguB HfaWHO2h7Xpvf3bNKQLn+85zRL1T2CouItGU0ueKOWYwS4iV1ZLfYkuZJLowLS4B 19s/vzcb/qKLPWHHMPRBY910mFJuhOREphtfAurkI5MotOccJZ/1xyvW9F8wTBKD IhZLRv5rsryacU+w4+XUkRBlv7zBzNb5wVM7kMIg2zzH+422gdAPmNgPIgrcc6ZG K3Hifk/o6qApn6wuyZJa =VDWZ -----END PGP SIGNATURE----- --Apple-Mail=_E9685780-00DD-4E91-BDB8-9DF080D3B207-- 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 From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 14:03:53 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 99C4CD02 for ; Mon, 16 Mar 2015 14:03:53 +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 54956391 for ; Mon, 16 Mar 2015 14:03:52 +0000 (UTC) Received: (qmail 23044 invoked from network); 16 Mar 2015 14:03:51 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Mar 2015 14:03:51 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 10:03:51 -0400 (EDT) Received: (qmail 4301 invoked from network); 16 Mar 2015 14:03:51 -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 14:03:51 -0000 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 62E8CB1E002; Mon, 16 Mar 2015 07:03:48 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload Message-Id: <90144A01-AD41-4B9A-B040-D342B60EAE02@dsl-only.net> Date: Mon, 16 Mar 2015 07:03:49 -0700 To: FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) 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 14:03:53 -0000 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-NODEBU= G powerpc powerpc64 With my limping-along powerpc64-xtoolchain-gcc being used on a powerpc64 = with CROSS_TOOLCHAIN=3Dpowerpc64-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_ostream' 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 =3D char; = _Traits =3D std::__1::char_traits]^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 =3D char; _Traits =3D = std::__1::char_traits]^M basic_ostream<_CharT, _Traits>::operator<<(basic_ios&^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 =3D char; _Traits =3D std::__1::char_traits]^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 = =3D char; _Traits =3D std::_ _1::char_traits]^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 =3D char; _Traits =3D std::__1::char_traits]^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 =3D char; _Traits =3D std::__1::char_traits]^M basic_ostream<_CharT, _Traits>::operator<<(basic_streambuf* __sb)^M ^^M /usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:907:1: note: = std::__1::basic_ostream& = std::__1::operator<<(std::__1::basic_ostream&, const = unsigned char*) [with _Traits =3D std::__1::char_traits]^M operator<<(basic_ostream& __os, const unsigned char* = __str)^M ^^M /usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:899:1: note: = std::__1::basic_ostream& = std::__1::operator<<(std::__1::basic_ostream&, const = signed char*) [with _Traits =3D std::__1::char_traits]^M operator<<(basic_ostream& __os, const signed char* = __str)^M ^^M /usr/obj/usr/srcC/tmp/usr/include/c++/v1/ostream:892:1: note: = std::__1::basic_ostream& = std::__1::operator<<(std::__1::basic_ostream&, const = char*) [with _Traits =3D std::__ 1::char_traits]^M operator<<(basic_ostream& __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 =3D char ; _Traits =3D std::__1::char_traits]^M operator<<(basic_ostream<_CharT, _Traits>& __os, const char* __strn)^M ^^M Other context details: make CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ WITHOUT_CLANG_BOOTSTRAP=3D \ WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG=3D WITHOUT_CLANG_EXTRAS=3D = WITHOUT_CLANG_FULL=3D \ WITHOUT_LLDB=3D \ WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_BINUTILS=3D buildworld buildkernel KERNCONF=3DGENERIC64vtsc-NODEBUG \ TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 (Yes I was being paranoid about various automatic settings that are = based on other ones. Any form of WITH_CLANG=3D blocks getting as far as = I did above.) This is a clang-not-in-use context (in fact not built at all, not even = an old one present), but in order to get by an issue where gcc 4.2.1 is = unfortunately used but was being told -std=3Dc++11 based on = clang.build.mk during some of my experiments, I have the local/personal = hack: # svnlite diff lib/clang/clang.build.mk Index: 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 --- lib/clang/clang.build.mk (revision 279514) +++ 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} As has been pointed out by Dimitry Andric: this hack is not appropriate = to the FreeBSD code base since it would only set up -std=3Dc++11 for = clang contexts were CXXFLAGS+=3D${CXXFLAGS.${COMPILER_TYPE}} was also in = use. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 14:41:46 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 2555B5A3; Mon, 16 Mar 2015 14:41:46 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E57B9B37; Mon, 16 Mar 2015 14:41:45 +0000 (UTC) Received: by igcqo1 with SMTP id qo1so43658982igc.0; Mon, 16 Mar 2015 07:41:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fku9QYkdygT+fqL+37Sb4scrTtz1mxlZOWUs7FeDJZo=; b=cJZRd8bW9GWh7Z+GZZgDtgCcPZFO1q1xamTMNEnzUnr6ezMdJqveOqsAq1gLWnXGAk FWlwUezre/91B72MpLRRJC1TH6cFK1TfXw1TWUzCkL3N+G2n/Kf83vmr2DZT3259qdG0 RHwLguCRBbv5jtuExZ/ZCyxmZGxsCvdX5MuvlMd8FtNtPBsWWj1UdZmC5M6eaWDq9lOc Wl+Gi+vpOo2hGCAuBDEgk0vkEFBedkWf0qTc5KA7oSVVMG8ohHBYRourAIpKuaipaS/q lJ+ZQeuG15DemSyijRmAK/Vsmw1fEGCQ6Zn381EiSyV+Y6c3qdqjetb657mw09umbJTL AmHA== MIME-Version: 1.0 X-Received: by 10.107.8.215 with SMTP id h84mr83698441ioi.89.1426516905317; Mon, 16 Mar 2015 07:41:45 -0700 (PDT) Received: by 10.107.156.75 with HTTP; Mon, 16 Mar 2015 07:41:45 -0700 (PDT) In-Reply-To: <90144A01-AD41-4B9A-B040-D342B60EAE02@dsl-only.net> References: <90144A01-AD41-4B9A-B040-D342B60EAE02@dsl-only.net> Date: Mon, 16 Mar 2015 10:41:45 -0400 Message-ID: Subject: Re: powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload From: Ryan Stone To: Mark Millard Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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 14:41:46 -0000 This should have been fixed in r276760: https://svnweb.freebsd.org/changeset/base/279760 From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 15:12:58 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 7F70BCA for ; Mon, 16 Mar 2015 15:12:58 +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 1ECFFF6E for ; Mon, 16 Mar 2015 15:12:57 +0000 (UTC) Received: (qmail 32028 invoked from network); 16 Mar 2015 15:12:54 -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 15:12:54 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 11:12:54 -0400 (EDT) Received: (qmail 15767 invoked from network); 16 Mar 2015 15:12:30 -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 15:12:30 -0000 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 0A3B31C43B7; Mon, 16 Mar 2015 08:12:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64-xtoolchain-gcc (gcc 4.9.1) reports: /usr/srcC/lib/libnv/tests/dnv_tests.cc:453:2: error: ambiguous overload From: Mark Millard In-Reply-To: Date: Mon, 16 Mar 2015 08:12:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A120641-FD18-4751-8695-0AF8FF3BC960@dsl-only.net> References: <90144A01-AD41-4B9A-B040-D342B60EAE02@dsl-only.net> To: Ryan Stone 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 15:12:58 -0000 On 2015-Mar-16, at 07:41 AM, Ryan Stone wrote: > This should have been fixed in r276760: >=20 > 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. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 16 18:01:23 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 755EDF32 for ; Mon, 16 Mar 2015 18:01:23 +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 1FD9EA86 for ; Mon, 16 Mar 2015 18:01:22 +0000 (UTC) Received: (qmail 5211 invoked from network); 16 Mar 2015 18:01:20 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 16 Mar 2015 18:01:20 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 14:01:20 -0400 (EDT) Received: (qmail 12364 invoked from network); 16 Mar 2015 18:01:20 -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 18:01:20 -0000 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 6D8661C439E; Mon, 16 Mar 2015 11:01:16 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64-xtoolchain-gcc (gcc 4.9.1): Expects to find /usr/lib/libc++.so.1 before it is installed there; libcxxrt.so too... Message-Id: <45FA29A2-73BA-4148-AA85-B766EF69F1A1@dsl-only.net> Date: Mon, 16 Mar 2015 11:01:18 -0700 To: FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) 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 18:01:23 -0000 Basic context (more details later): # freebsd-versino -ku ; uname -ap su: freebsd-versino: not found 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-NODEBU= G powerpc powerpc64 Attempting rebuild 11.0-CURRENT r279514 using powerpc64-xtoolchain-gcc's = CROSS_TOOLCHAIN=3Dpowerpc64-gcc . (I've broken up the long line below to make it easier to parse.) /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ \ -isystem /usr/obj/usr/srcC/tmp/usr/include -L/usr/obj/usr/srcC/tmp/usr/lib = -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 \ -std=3Dgnu++11 \ -L/usr/obj/usr/srcC/tmp/../lib/libc++ \ -O2 -pipe -fstack-protector \ -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized \ -L/usr/obj/usr/srcC/tmp/usr/lib/private \ -rpath /usr/lib/private -rpath /usr/lib/private \ -o dnv_tests dnv_tests.o \ /usr/obj/usr/srcC/lib/atf/libatf-c++/libatf-c++.so \ /usr/obj/usr/srcC/lib/atf/libatf-c/libatf-c.so \ -lnv /usr/local/bin/powerpc64-freebsd-ld: cannot find /usr/lib/libc++.so.1 /usr/local/bin/powerpc64-freebsd-ld: cannot find /usr/lib/libcxxrt.so collect2: error: ld returned 1 exit status *** Error code 1 The the time of the failure the files are actually at: # find / -type f -name 'libc++*' -print | more /usr/src/lib/libc++/libc++.ldscript /usr/obj/usr/srcC/lib/libc++/libc++.so.1 /usr/obj/usr/srcC/lib/libc++/libc++.a /usr/obj/usr/srcC/lib/libc++/libc++_p.a /usr/obj/usr/srcC/tmp/usr/lib/libc++.a /usr/obj/usr/srcC/tmp/usr/lib/libc++.so.1 /usr/obj/usr/srcC/tmp/usr/lib/libc++.so /usr/srcC/lib/libc++/libc++.ldscript # ls -FPal /usr/obj/usr/srcC/lib/libc++/libc++.so.1 = /usr/obj/usr/srcC/tmp/usr/lib/libc++.so.1 -rwxr-xr-x 1 root wheel 1318912 Mar 16 08:53 = /usr/obj/usr/srcC/lib/libc++/libc++.so.1* -rwxr-xr-x 1 root wheel 1318912 Mar 16 08:53 = /usr/obj/usr/srcC/tmp/usr/lib/libc++.so.1* # find / -type f -name 'libcxxrt*' -print | more /usr/obj/usr/srcC/lib/libcxxrt/libcxxrt.so.1 /usr/obj/usr/srcC/lib/libcxxrt/libcxxrt.a /usr/obj/usr/srcC/lib/libcxxrt/libcxxrt_p.a /usr/obj/usr/srcC/tmp/lib/libcxxrt.so.1 /usr/obj/usr/srcC/tmp/usr/lib/libcxxrt.a # ls -FPal /usr/obj/usr/srcC/lib/libcxxrt/libcxxrt.so.1 = /usr/obj/usr/srcC/tmp/lib/libcxxrt.so.1 -rwxr-xr-x 1 root wheel 134616 Mar 16 08:41 = /usr/obj/usr/srcC/lib/libcxxrt/libcxxrt.so.1* -rwxr-xr-x 1 root wheel 134616 Mar 16 08:41 = /usr/obj/usr/srcC/tmp/lib/libcxxrt.so.1* Notably there is no libcxxrt.so without the .1 suffix anywhere. More context details: make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ WITHOUT_CLANG_BOOTSTRAP=3D \ WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG=3D WITHOUT_CLANG_EXTRAS=3D = WITHOUT_CLANG_FULL=3D \ WITHOUT_LLDB=3D \ WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_BINUTILS=3D \ buildworld buildkernel \ KERNCONF=3DGENERIC64vtsc-NODEBUG \ TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 also I retried after the first report with... make -DNO_CLEAN CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ WITHOUT_CLANG_BOOTSTRAP=3D \ WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG=3D WITHOUT_CLANG_EXTRAS=3D = WITHOUT_CLANG_FULL=3D \ WITHOUT_LLDB=3D \ WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_BINUTILS=3D \ buildworld buildkernel \ KERNCONF=3DGENERIC64vtsc-NODEBUG \ TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 and it stopped at the same point for the same issue. # svnlite info Path: . Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) ( lib/libnv/tests/dnv/tests.cc and lib/libnv/tests/dnv/tests.cc have = been updated to -r279760 status to get rid of compile errors.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 00:04:43 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89695576 for ; Tue, 17 Mar 2015 00:04:43 +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 2D6AFD08 for ; Tue, 17 Mar 2015 00:04:42 +0000 (UTC) Received: (qmail 10431 invoked from network); 17 Mar 2015 00:04:41 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 00:04:41 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 20:04:41 -0400 (EDT) Received: (qmail 7241 invoked from network); 17 Mar 2015 00:04:41 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 00:04:41 -0000 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 B2A101C439E; Mon, 16 Mar 2015 17:04:35 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) Date: Mon, 16 Mar 2015 17:04:38 -0700 Message-Id: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 00:04:43 -0000 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-NODEBU= G 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).=20 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 00:18:44 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 63543971 for ; Tue, 17 Mar 2015 00:18:44 +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 0C8F5E0B for ; Tue, 17 Mar 2015 00:18:43 +0000 (UTC) Received: (qmail 5139 invoked from network); 17 Mar 2015 00:18:42 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 00:18:42 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 20:18:42 -0400 (EDT) Received: (qmail 19751 invoked from network); 17 Mar 2015 00:18:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 00:18:42 -0000 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 7A18E1C439E; Mon, 16 Mar 2015 17:18:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared Date: Mon, 16 Mar 2015 17:18:40 -0700 Message-Id: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 00:18:44 -0000 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 01:23:39 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F407535E; Tue, 17 Mar 2015 01:23:38 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 D2C3267F; Tue, 17 Mar 2015 01:23:38 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2H1NTvP022641 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Mar 2015 18:23:29 -0700 Message-ID: <55078211.3080704@freebsd.org> Date: Mon, 16 Mar 2015 18:23:29 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> In-Reply-To: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVbki42I0w1WY536Vq8nkEm3UQN1elqms+XgDHEmLZxnMD3yStWm3+Fv9jS3Nc6joLWZU8DGcS5xrn3NU0n3CqGney3AUyROb8U= X-Sonic-ID: C;OM7yN0TM5BG+Gr5YxQPdhw== M;znwhOETM5BG+Gr5YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 01:23:39 -0000 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-unsubscribe@freebsd.org" > From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 03:00:59 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49F1FF7A for ; Tue, 17 Mar 2015 03:00:59 +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 D4C46F8B for ; Tue, 17 Mar 2015 03:00:58 +0000 (UTC) Received: (qmail 14861 invoked from network); 17 Mar 2015 03:00:57 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 03:00:57 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 23:00:57 -0400 (EDT) Received: (qmail 31494 invoked from network); 17 Mar 2015 03:00:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 03:00:56 -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 3438A1C4052; Mon, 16 Mar 2015 20:00:50 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <55078211.3080704@freebsd.org> Date: Mon, 16 Mar 2015 20:00:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13ED08B5-0FC7-43CC-A5DA-73C9AA2D5220@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <55078211.3080704@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@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: Tue, 17 Mar 2015 03:00:59 -0000 > On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn = wrote: >=20 > 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 Quoting for the "which compiler" part: "It used gcc5 to bootstrap as = there was no clang present and that is the only gcc port installed". The evidence for this was watching top -PaSCHopid while it worked on the = installation. As for the FBSDG5C0 SSD's 11.0-CURRENT history for compilers: gcc 4.2.1 present. clang not present. (Not 3.4.1, not 3.5, not 3.6. 3.4.1 was lost in the 10.1-STABLE -> 11.0-CURRENT conversion when I did = delete-old, not realizing that I'd end up with no clang at all and no obvious way = to build one on the powerpc64s/powerpcs.) (None of the below were ever on any 10.1-STABLE SSD as of when I did the = copies and conversion of some to 11.0-CURRENT.) powerpc64-xtoolchain-gcc present (and so powerpc64-gcc), installed = recently for the first time ever. This was the first ever = not-built-into-world compiler that I've installed on any media. The = powerpc64-gcc installer has a file naming problem for powerpc64 hosts I = had to put copies of 5 files that it created under the names it later = looked for them to finish this install (names not prefixed -> prefixed, = one file copied to another place). gcc5 installed just days ago, the second ever ports-compiler installed. = The install had no problems. I will note that I have started an installation of lang/clang36 on a = powerpc (non-64) 11.0-CURRENT that has/had only gcc 4.2.1 and clang = 3.4.1. Watching with top -PaSCHopid shows that it is doing a lang/gcc = installation as part of its bootstrap, at this point that means 4.8.4. So it is not using gcc 4.2.1. Again for this SSD there is no history of = compiler installs other than those that are part of world. clang 3.4.1 = exists because I did not get around to doing delete-old before I noticed = that I ended up with no clang as a result. This is the only copy of = clang 3.4.1 that survived my ignorance to end up on 11.0-CURRENT. I have another powerpc (non-64) 11.0-CURRENT SSD that does not have = powerpc64-gcc nor clang but does have gcc5 already. Again gcc5 installed = in the last few days. Again before the installation there had only ever = been built-into-world compilers. I've started a lang/CLANG36 install = here as well. We will see how each of these goes. Side note: You can tell I got past the booting/memory-corruption = problems on the G5 PowerMacs recently (via Powermac specific builds). = I'm now exploring other things in FreeBSD. :) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn = wrote: 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): >=20 > # 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-NODEBU= G powerpc powerpc64 >=20 >=20 > The problem: >=20 > portmaster -tDK --no-confirm lang/clang36 is how I started the build. >=20 > The error reported was for in MSVCToolChain.cpp's member function: >=20 > bool = clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, = int&) const >=20 > The report was: >=20 > MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared > ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); >=20 >=20 > 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. >=20 >=20 >=20 > Context details: >=20 > # 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) >=20 > It used gcc5 to bootstrap as there was no clang present and that is = the only gcc port installed: >=20 > # 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) >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 03:37:54 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8306FE4D for ; Tue, 17 Mar 2015 03:37:54 +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 3A80E644 for ; Tue, 17 Mar 2015 03:37:53 +0000 (UTC) Received: (qmail 27631 invoked from network); 17 Mar 2015 03:37:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 03:37:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 16 Mar 2015 23:37:52 -0400 (EDT) Received: (qmail 23711 invoked from network); 17 Mar 2015 03:37:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 03:37:52 -0000 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 AD09C1C439E; Mon, 16 Mar 2015 20:37:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> Date: Mon, 16 Mar 2015 20:37:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 03:37:54 -0000 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::s= tring&, 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 05:36:54 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 99BA0A25 for ; Tue, 17 Mar 2015 05:36:54 +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 45A55103 for ; Tue, 17 Mar 2015 05:36:53 +0000 (UTC) Received: (qmail 22682 invoked from network); 17 Mar 2015 05:36:52 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 05:36:52 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 01:36:52 -0400 (EDT) Received: (qmail 24173 invoked from network); 17 Mar 2015 05:36:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 05:36:52 -0000 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 DCEA41C4052; Mon, 16 Mar 2015 22:36:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> Date: Mon, 16 Mar 2015 22:36:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 05:36:54 -0000 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 and other times . (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 = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = 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::s= tring&, 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 06:00:54 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E514B8 for ; Tue, 17 Mar 2015 06:00:54 +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 D856D2FE for ; Tue, 17 Mar 2015 06:00:53 +0000 (UTC) Received: (qmail 23064 invoked from network); 17 Mar 2015 06:00:52 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 06:00:52 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 02:00:52 -0400 (EDT) Received: (qmail 23909 invoked from network); 17 Mar 2015 06:00:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 06:00:51 -0000 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 A62651C439E; Mon, 16 Mar 2015 23:00:44 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) From: Mark Millard In-Reply-To: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> Date: Mon, 16 Mar 2015 23:00:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> References: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 06:00:54 -0000 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 where an include = of 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:04 PM, 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-NODEBU= G 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).=20 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 09:19:53 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32598AE5 for ; Tue, 17 Mar 2015 09:19:53 +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 D7F8BCCB for ; Tue, 17 Mar 2015 09:19:52 +0000 (UTC) Received: (qmail 4437 invoked from network); 17 Mar 2015 09:19:45 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 09:19:45 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 05:19:45 -0400 (EDT) Received: (qmail 16072 invoked from network); 17 Mar 2015 09:19:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 09:19:44 -0000 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 DB0D41C4052; Tue, 17 Mar 2015 02:19:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: Date: Tue, 17 Mar 2015 02:19:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 09:19:53 -0000 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 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = 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 and other times . (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 = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = 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::s= tring&, 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 09:26:36 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 CD05BD9E for ; Tue, 17 Mar 2015 09:26:36 +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 80BB1DC0 for ; Tue, 17 Mar 2015 09:26:36 +0000 (UTC) Received: (qmail 4551 invoked from network); 17 Mar 2015 09:26:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 09:26:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 05:26:35 -0400 (EDT) Received: (qmail 21852 invoked from network); 17 Mar 2015 09:26:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 09:26:34 -0000 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 EBE441C43AD; Tue, 17 Mar 2015 02:26:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> Date: Tue, 17 Mar 2015 02:26:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 09:26:36 -0000 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = 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 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = 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 and other times . (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 = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = 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::s= tring&, 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 17:57:07 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12BACAD8 for ; Tue, 17 Mar 2015 17:57:07 +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 BB44FB3 for ; Tue, 17 Mar 2015 17:57:06 +0000 (UTC) Received: (qmail 19955 invoked from network); 17 Mar 2015 17:57:05 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 17:57:05 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 13:57:05 -0400 (EDT) Received: (qmail 21747 invoked from network); 17 Mar 2015 17:57:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 17:57:04 -0000 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 8BBC41C4052; Tue, 17 Mar 2015 10:57:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: Date: Tue, 17 Mar 2015 10:57:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 17:57:07 -0000 Adding a #include 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 had been included = somewhere or not. It might be that neither header had been included. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard = 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = 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 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = 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 and other times . (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 = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = 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::s= tring&, 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 20:24:46 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9523B646 for ; Tue, 17 Mar 2015 20:24:46 +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 485966C4 for ; Tue, 17 Mar 2015 20:24:45 +0000 (UTC) Received: (qmail 385 invoked from network); 17 Mar 2015 20:24:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 20:24:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 16:24:43 -0400 (EDT) Received: (qmail 12690 invoked from network); 17 Mar 2015 20:24:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 20:24:43 -0000 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 A11B91C43A6; Tue, 17 Mar 2015 13:24:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: Date: Tue, 17 Mar 2015 13:24:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 20:24:46 -0000 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 . (So also no explicit include of , = just like the official source file.) It failed: MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, 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 . MSVCToolChain.cpp does not directly or indirectly include . 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 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.) //=3D=3D=3D--- ToolChains.cpp - ToolChain Implementations = -----------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #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 // Include the necessary headers to interface with the Windows registry = and // environment. ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 10:57 AM, Mark Millard = wrote: Adding a #include 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 had been included = somewhere or not. It might be that neither header had been included. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard = 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = 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 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = 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 and other times . (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 = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = 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::s= tring&, 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 17 21:16:42 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D5268DF for ; Tue, 17 Mar 2015 21:16:42 +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 F3C80D30 for ; Tue, 17 Mar 2015 21:16:41 +0000 (UTC) Received: (qmail 9099 invoked from network); 17 Mar 2015 21:16:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 17 Mar 2015 21:16:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 17:16:40 -0400 (EDT) Received: (qmail 16445 invoked from network); 17 Mar 2015 21:16:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Mar 2015 21:16:40 -0000 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 282F21C439E; Tue, 17 Mar 2015 14:16:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared From: Mark Millard In-Reply-To: <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> Date: Tue, 17 Mar 2015 14:16:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <93E56954-B418-489A-B437-EAB73DF758CB@dsl-only.net> References: <728D7136-99BF-4D92-BD7B-2A049517B47D@dsl-only.net> <722DBABA-1E03-434E-ACB4-55A1E69E8AAA@dsl-only.net> <4A490783-D724-4C81-A99E-0CBB20650559@dsl-only.net> <7A4844FD-8AF2-4431-ADC2-F172626097B1@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Tue, 17 Mar 2015 21:16:42 -0000 Looking at = https://github.com/clang-omp/clang_trunk/blob/master/lib/Driver/MSVCToolCh= ain.cpp shows that the modern source code has std::sscanf and = use so that is likely the better direction to go. What I saw when I = looked was: //=3D=3D=3D--- ToolChains.cpp - ToolChain Implementations = -----------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #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 // Include the necessary headers to interface with the Windows registry = and // environment. ... if (!sdkVersion.empty()) std::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor); return hasSDKDir && !path.empty(); ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 01:24 PM, Mark Millard = wrote: 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 . (So also no explicit include of , = just like the official source file.) It failed: MSVCToolChain.cpp: In member function 'bool = clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::s= tring&, 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 . MSVCToolChain.cpp does not directly or indirectly include . 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 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.) //=3D=3D=3D--- ToolChains.cpp - ToolChain Implementations = -----------------------=3D=3D=3D// // // The LLVM Compiler Infrastructure // // This file is distributed under the University of Illinois Open Source // License. See LICENSE.TXT for details. // = //=3D=3D=3D---------------------------------------------------------------= -------=3D=3D=3D// #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 // Include the necessary headers to interface with the Windows registry = and // environment. ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 10:57 AM, Mark Millard = wrote: Adding a #include 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 had been included = somewhere or not. It might be that neither header had been included. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:26 AM, Mark Millard = 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-17, at 02:19 AM, Mark Millard = 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 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 10:36 PM, Mark Millard = 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 and other times . (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 = somewhere for that context. (Having in addition is fine.) The rule is as follows, using an example. The C++ standard (various = vintages) has at least one vintage that uses vs. as = an example for... "The header assuredly provides its declarations and = definitions within the namespace std. It may also provide these names = within the global namespace. The header 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... only guarantees: int std::sscanf( const char* buffer, const char* format, ... ); 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. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 08:37 PM, Mark Millard = 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::s= tring&, 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:18 PM, 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-NODEBU= G 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 18 03:02:52 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 70EF9AE9 for ; Wed, 18 Mar 2015 03:02:52 +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 28FD1BD4 for ; Wed, 18 Mar 2015 03:02:51 +0000 (UTC) Received: (qmail 26462 invoked from network); 18 Mar 2015 03:02:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Mar 2015 03:02:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 17 Mar 2015 23:02:49 -0400 (EDT) Received: (qmail 526 invoked from network); 18 Mar 2015 03:02:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Mar 2015 03:02:49 -0000 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 C28601C439E; Tue, 17 Mar 2015 20:02:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) From: Mark Millard In-Reply-To: <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> Date: Tue, 17 Mar 2015 20:02:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1E76AC30-BCB1-4FEE-8FA5-5EECF1F757E8@dsl-only.net> References: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> To: FreeBSD PowerPC ML , freebsd-ports@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org 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: Wed, 18 Mar 2015 03:02:52 -0000 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 =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/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 @@ =20 --- utils/llvm-build/llvmbuild/main.py.orig +++ utils/llvm-build/llvmbuild/main.py -@@ -633,7 +633,13 @@ +@@ -633,7 +633,14 @@ =20 # 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', =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 11:00 PM, Mark Millard = 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 where an include = of 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-16, at 05:04 PM, 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-NODEBU= G 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).=20 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=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 18 06:49:08 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DFBA195 for ; Wed, 18 Mar 2015 06:49:08 +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 03328273 for ; Wed, 18 Mar 2015 06:49:07 +0000 (UTC) Received: (qmail 31043 invoked from network); 18 Mar 2015 06:49:06 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 18 Mar 2015 06:49:06 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 18 Mar 2015 02:49:06 -0400 (EDT) Received: (qmail 12148 invoked from network); 18 Mar 2015 06:49:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Mar 2015 06:49:05 -0000 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 65EC31C4052; Tue, 17 Mar 2015 23:49:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 10.1-STABLE [WITH_DEBUG] context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it From: Mark Millard In-Reply-To: <21202F99-B759-4888-8C7E-5F65D4346F96@dsl-only.net> Date: Tue, 17 Mar 2015 23:49:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54FC7D92.3010405@freebsd.org> <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> <21202F99-B759-4888-8C7E-5F65D4346F96@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@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: Wed, 18 Mar 2015 06:49:08 -0000 Looks like I forgot to forward Brad King's 2015-Mar-11 note that KWSys = and CMake have the "static" fix that allows non-inlining debug builds of = ctest and other programs to handle the TOC register usage appropriately: > The change is now in KWSys 'master' and I've updated > the copy within CMake: >=20 > KWSys 2015-03-10 (4a698414) > http://cmake.org/gitweb?p=3Dcmake.git;a=3Dcommitdiff;h=3D9a427f86 >=20 > Merge branch 'upstream-kwsys' into update-kwsys > http://cmake.org/gitweb?p=3Dcmake.git;a=3Dcommitdiff;h=3De433223d >=20 > -Brad =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-10, at 01:11 PM, Mark Millard = wrote: Brad King is adding the missing static to _stl_next_prime in KWSys and = from there it will eventually propagate into CMake's code base. Actually = in KWSys both static's are to be added. ( = http://review.source.kitware.com/#/c/19465/ ) Brad wrote that CMake's code base had added the static to = _get_stl_prime_list to handle a linking problem in some environment. = (Despite not knowing of KWSys I had guessed that there was some reason = why that static was there: that is why I suggested the direction of = making _stl_next_prime match instead of suggesting removing the static = on _get_stl_prime_list.) Once propagated the updates will make KWSys and = CMake's code again match in this area. So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG=3D= to be better behaved for CMake's programs that use it's hashtable.hxx . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-9, at 08:09 AM, Mark Millard wrote: I've discovered why/how WITH_DEBUG=3D ends up with cmake's = /usr/local/bin/ctest messed up for PIC code generation (powerpc64 = context). A source code fix that avoids the problem is likely to change = cmake's hashtable.hxx that has inline size_t _stl_next_prime(size_t __n) { const unsigned long* __first =3D get_stl_prime_list(); const unsigned long* __last =3D get_stl_prime_list() + = (int)_stl_num_primes; const unsigned long* pos =3D cmsys_stl::lower_bound(__first, __last, = __n); return pos =3D=3D __last ? *(__last - 1) : *pos; } to also indicate static for it like the .hxx file has for static inline const unsigned long* get_stl_prime_list() { static const unsigned long _stl_prime_list[_stl_num_primes] =3D { 5ul, 11ul, 23ul, 53ul, 97ul, 193ul, 389ul, 769ul, 1543ul, 3079ul, 6151ul, 12289ul, 24593ul, 49157ul, 98317ul, 196613ul, 393241ul, 786433ul, 1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul, 50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul, 1610612741ul, 3221225473ul, 4294967291ul }; return &_stl_prime_list[0]; } NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that = exist in the source code. The details for what is going on follow... There are 7 instances of get_stl_prime_list's code in my = /usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 = values to allow finding appropriate _stl_prime_list addresses in various = places that include the header file. Each code instance from my build's = /usr/local/bin/ctest is shown below. (Note that the = ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the = distinct addresses.) But there is only 1 instance of _stl_next_prime's code in = /usr/local/bin/ctest, also shown below. This routine directly calls the = first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, = effectively forcing the %r2 offset from that code to always be used = --and so generating garbage addresses for 6 of the 7 static contexts. 6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused. But most of the initial usage of _stl_next_prime in execution order = happens to have the %r2 value that goes with the first = ._ZN5cmsysL18get_stl_prime_listEv routine. That is why = /usr/local/bin/ctest dies as late as it does. I have observed the indicated behavior leading up to the crash under gdb = as well. 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2976(r2) 00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2720(r2) 000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,2088(r2) 00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,11344(r2) 000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-32728(r2) 00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-26608(r2) 000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-21280(r2) 00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) And here is the only _stl_next_prime routine: 0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr r0 0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std r31,-8(r1) 000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std r0,16(r1) 0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu r1,-176(r1) 0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr r31,r1 0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std = r3,224(r31) 000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr r0,r3 0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std = r0,128(r31) 0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr r9,r3 00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi r0,r9,248 00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std = r0,120(r31) 00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld = r3,128(r31) 00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld = r4,120(r31) 00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi r0,r31,224 00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr r5,r0 00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl = 0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_> 00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove = 4*cr7+so,4*cr7+so 00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr r0,r3 00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std = r0,112(r31) 00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld = r9,112(r31) 00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld = r0,120(r31) 00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd cr7,r9,r0 00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne- = cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> 00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld = r9,120(r31) 00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi r9,r9,-8 00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld r9,0(r9) 00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std = r9,144(r31) 00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b = 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> 00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld = r9,112(r31) 00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9) 00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std = r9,144(r31) 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld = r0,144(r31) 00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr r3,r0 0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld r1,0(r1) 0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld r0,16(r1) 0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr r0 000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld r31,-8(r1) 0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr 0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0 0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001 000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz r0,1(r1) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 06:35 PM, Mark Millard wrote: Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cyan = "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.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 > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 18 14:32:27 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 A634E1B1; Wed, 18 Mar 2015 14:32:27 +0000 (UTC) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2D32C1; Wed, 18 Mar 2015 14:32:27 +0000 (UTC) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 419FE5A9F27; Wed, 18 Mar 2015 14:32:21 +0000 (UTC) Date: Wed, 18 Mar 2015 14:32:21 +0000 From: Brooks Davis To: Mark Millard Subject: Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project) Message-ID: <20150318143221.GB52442@spindle.one-eyed-alien.net> References: <9682273F-8B85-4351-AB2B-011240D40327@dsl-only.net> <160E2B60-047A-4E5B-A258-334155CDEC0B@dsl-only.net> <1E76AC30-BCB1-4FEE-8FA5-5EECF1F757E8@dsl-only.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <1E76AC30-BCB1-4FEE-8FA5-5EECF1F757E8@dsl-only.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@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: Wed, 18 Mar 2015 14:32:27 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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, su= ch as illustrated below. >=20 > $ svnlite diff /usr/ports/lang/clang36 > Index: /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_mai= n.py > =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/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.p= y (revision 381120) > +++ /usr/ports/lang/clang36/files/patch-utils_llvm-build_llvmbuild_main.p= y (working copy) > @@ -3,7 +3,7 @@ > =20 > --- utils/llvm-build/llvmbuild/main.py.orig > +++ utils/llvm-build/llvmbuild/main.py > -@@ -633,7 +633,13 @@ > +@@ -633,7 +633,14 @@ > =20 > # 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', >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-16, at 11:00 PM, Mark Millard wrote: >=20 > The 2 powerpc (non-64) build attempts for clang 3.6 did not get this prob= lem. >=20 > So this specific problem is powerpc64 specific. >=20 > 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 ins= talled lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.) >=20 > Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 al= ready installed first) still reports an error for not declaring ::sscanf, j= ust like powerpc64 based on gcc5 for bootstrapping did. >=20 > (This might be llvm/clang making use of only where an include of= would be required to be involved in order to guarantee the :: (g= lobal) declaration/definition. The way the C++ standard (all vintages) is w= ritten gcc 4.8.4 and gcc5 could be this different and both be valid/conform= ing.) >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-16, at 05:04 PM, Mark Millard wrote: >=20 > Basic context (more context details listed later): >=20 > # freebsd-version -ku; uname -ap > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 1= 1 19:23:14 PDT 2015 root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/s= ys/GENERIC64vtsc-NODEBUG powerpc powerpc64 >=20 >=20 > The problem: >=20 > portmaster -tDK --no-confirm lang/clang36 is how I started the build. >=20 > The error report was after it reported entering the directory: >=20 > /usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang= /lib/Driver/ >=20 > The report was: >=20 > llvm-build: error: invalid native target: 'powerpc64' (not in project) >=20 >=20 > I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 l= ikely does. I've not yet tried from a powerpc (non-64) FreeBSD build. >=20 > I'll note that with top -PaSCHopid I watched it compile the PowerPc code = generator software: it shoudl be able to handle PowerPCs fine. >=20 > My guess is a conversion of naming conventions is required someplace: >=20 > FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.) >=20 > This likely would matter for little endian naming as well (ppc64le on the= clang end of things I expect).=20 >=20 >=20 >=20 >=20 > Context details: >=20 > # 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) >=20 > It used gcc5 to bootstrap as there was no clang present and that is the o= nly gcc port installed: >=20 > # 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) >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.o= rg" >=20 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUJjHQACgkQXY6L6fI4GtSBuwCgsvPnavBdg0zrxEjKlle3mLjw qJMAoMAG5rw0I1GC/NbyzA7D23VR17Ju =fGr3 -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-toolchain@FreeBSD.ORG Wed Mar 18 21:39:09 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4AA2CF3F for ; Wed, 18 Mar 2015 21:39:09 +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 DC163EB5 for ; Wed, 18 Mar 2015 21:39:08 +0000 (UTC) Received: (qmail 11574 invoked from network); 18 Mar 2015 21:39:01 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Mar 2015 21:39:01 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 18 Mar 2015 17:39:01 -0400 (EDT) Received: (qmail 26815 invoked from network); 18 Mar 2015 21:39:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Mar 2015 21:39:01 -0000 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 12A131C4052; Wed, 18 Mar 2015 14:38:56 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT: CROSS_TOOLCHAIN=powerpc64-gcc rejects -m elf32ppc_fbsd for linking boot1.elf Date: Wed, 18 Mar 2015 14:38:58 -0700 Message-Id: <122C9C88-24F9-4FA7-BCAC-293ED0DB946A@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@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: Wed, 18 Mar 2015 21:39:09 -0000 Basic context (more details given later): > # freebsd-version -ku; uname -apKU > 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-NODEBU= G powerpc powerpc64 1100062 1100062 No clang is built or installed. The problem: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc WITHOUT_CLANG_BOOTSTRAP=3D = WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG=3D WITHOUT_CLANG_EXTRAS=3D = WITHOUT_CLANG_FULL=3D WITHOUT_LLDB=3D WITHOUT_GCC_BOOTSTRAP=3D = WITHOUT_GCC=3D buildworld buildkernel KERNCONF=3DGENERIC64vtsc-NODEBUG = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 processes up to: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE=20 > -m32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -m elf32ppc_fbsd -m elf32ppc_fbsd -o boot1.elf boot1.o = ashldi3.o syncicache.o -L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ and then gets for the above command... > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >=20 > *** [boot1.elf] Error code 1 >=20 > make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp > 1 error The -m options seems to be from the likes of... > # $FreeBSD: head/sys/boot/powerpc/Makefile.inc 227739 2011-11-19 = 19:25:57Z andreast $ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > LDFLAGS+=3D -m elf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" and (extracted from using find ... -print): > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/uboot/Makefile.inc > LD=3D"${LD} -m elf32ppc_fbsd" > /usr/srcC/Makefile.inc1 When I looked at "man gcc" I did not find any "-m text" options = or any -melf32ppc_fbsd option. It would suggest that "-m elf32ppc_fbsd" = is not normally valid --matching the complaints by = powerpc64-portbld-freebsd11.0-gcc. Is there a FreeBSD-specific addition to gcc missing in powerpc64-gcc? Context details: WITHOUT_CLANG=3D (bootstrap too) is important to getting this far in my = context. (It was in the make command shown earlier.) # more /etc/src.conf CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ NO_WERROR=3D The CC=3D, CXX=3D, CPP=3D assignments matching the XCC, XCXX, and XCPP = assignments for CROSS_TOOLCHAIN=3Dpowerpc64-gcc are important to getting = this far: otherwise gcc 4.2.1 is used for some things. I also listed = CROSS_BINUTILS_PREFIX and X_COMPILER_TYPE when I added the assignments. = I do not know if they are needed. libc++ include and library path handling did not automatically work so I = added the explicit CXXFLAGS+=3D and LDADD+=3D. If there had been a CXX = specific LDADDCXX I would have used it instead. NO_WERROR=3D is for avoiding stopping for the warnings: I'm not trying = to clean up the status relative to compiler warnings. # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/Makefile M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h needed an internal friend status established across = typename parameters in order to compile. I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. I build without ps3 in order to allow having both vt = and sc in the build. # ls -FPal /usr/local/include/iconv* -rw-r--r-- 1 root wheel 9348 Mar 12 02:47 = /usr/local/include/iconv.h_alt powerpc64-gcc automatically finds files in /usr/local/include/ such that = they can be used when others with different content but the same name = are appropriate. I renamed /usr/local/include/iconv.h to avoid it being = an example of that. I will not list how I got powerpc64-xtoolchain-gcc (and so = powerpc64-gcc) to finish installing on a powerpc64 11.0-CURRENT. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 19 02:40:39 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C91FC67 for ; Thu, 19 Mar 2015 02:40:39 +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 1F20F34A for ; Thu, 19 Mar 2015 02:40:38 +0000 (UTC) Received: (qmail 6520 invoked from network); 19 Mar 2015 02:40:37 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 02:40:37 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 18 Mar 2015 22:40:37 -0400 (EDT) Received: (qmail 588 invoked from network); 19 Mar 2015 02:40:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 02:40:37 -0000 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 949211C43A6; Wed, 18 Mar 2015 19:40:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 11.0-CURRENT: CROSS_TOOLCHAIN=powerpc64-gcc rejects -m elf32ppc_fbsd for linking boot1.elf From: Mark Millard In-Reply-To: <122C9C88-24F9-4FA7-BCAC-293ED0DB946A@dsl-only.net> Date: Wed, 18 Mar 2015 19:40:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <62E9089D-AF22-49F2-A20B-8719C1922EC7@dsl-only.net> References: <122C9C88-24F9-4FA7-BCAC-293ED0DB946A@dsl-only.net> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@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: Thu, 19 Mar 2015 02:40:39 -0000 It looks to me like the space between -m and elf32ppc_fbsd in "-m = elf32ppc_fbsd" is likely not allowed for powerpc64-gcc (gcc 4.9.1): (shown ignoring binary file matches) > # pwd > /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work > # find . -type f -exec grep elf32ppc_fbsd {} \; -print | more > #define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " = LINK_OS_FREEBSD_SPEC_DEF32 > ./gcc-4.9.1/gcc/config/rs6000/freebsd64.h > -melf32ppc_fbsd %{p:%nconsider using `-pg' instead of `-p' with = gprof(1)} %{v:-V} %{assert*} %{R*} %{rpath*} %{defsym*} = %{shared:-Bshareable %{h*} %{soname*}} %{!shared: %{!static: = %{rdynamic: -export-dynamic} %{!dynamic-linker:-dynamic-linker = /libexec/ld-elf32.so.1}} %{static:-Bstatic}} = %{symbolic:-Bsymbolic} > ./build-gcc/gcc/specs > #define LINK_OS_FREEBSD_SPEC32 "-melf32ppc_fbsd " = LINK_OS_FREEBSD_SPEC_DEF32 > = ./stage/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/plugin/inclu= de/config/rs6000/freebsd64.h This might explain the elf32gcc_fbsd file missing notices that I = reported before. However when I removed the spaces from the Makefile.inc*'s that use "-m = elf..." (see later) powerpc64-gcc produced: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE=20 > -m32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -melf32ppc_fbsd -melf32ppc_fbsd -o boot1.elf boot1.o = ashldi3.o syncicache.o -L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-melf32ppc_fbsd' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-melf32ppc_fbsd' It looks like elf32ppc_fbsd mode usage with such -m notation is = disallowed in powerpc64-gcc. [I tried a few experimental, manual gcc5 command lines and got the same = results there. So it may not be just powerpc64-gcc.] Being disallowed overall would imply that WITH_GCC_BOOTSTRAP=3D (4.2.1 = or some alternative) is required for such use and = /usr/srcC/Makefile.inc1 would need to make use of the alternative that = allows elf32ppc_fbsd where it is used. So for my purposes WITHOUT_LIB32=3D WITHOUT_BOOT=3D relative to seeing what can be done with powerpc64-xtoolchain-gcc: I'm = not checking if there is a different way to do an equivalent of = -melf32ppc_fbsd. The -m elf...'s that I tried changing were as below. I only tried = elf32ppc_fbsd contexts. > # svnlite diff /usr/srcC/Makefile.inc1 /usr/srcC/sys/boot | more > Index: /usr/srcC/Makefile.inc1 > =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/Makefile.inc1 (revision 279514) > +++ /usr/srcC/Makefile.inc1 (working copy) > @@ -396,7 +396,7 @@ > MACHINE_CPU=3D"i686 mmx sse sse2" > LIB32WMAKEFLAGS=3D \ > AS=3D"${AS} --32" \ > - LD=3D"${LD} -m elf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > + LD=3D"${LD} -melf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > =20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" > .if empty(TARGET_CPUTYPE) > @@ -406,7 +406,7 @@ > .endif > LIB32WMAKEENV=3D MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc > LIB32WMAKEFLAGS=3D \ > - LD=3D"${LD} -m elf32ppc_fbsd" > + LD=3D"${LD} -melf32ppc_fbsd" > .endif > =20 > =20 > Index: /usr/srcC/sys/boot/i386/Makefile.inc > =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/sys/boot/i386/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/i386/Makefile.inc (working copy) > @@ -14,7 +14,7 @@ > CFLAGS+=3D -m32 > ACFLAGS+=3D -m32 > # LD_FLAGS is passed directly to ${LD}, not via ${CC}: > -LD_FLAGS+=3D -m elf_i386_fbsd > +LD_FLAGS+=3D -melf_i386_fbsd > AFLAGS+=3D --32 > .endif > =20 > Index: /usr/srcC/sys/boot/ofw/Makefile.inc > =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/sys/boot/ofw/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/powerpc/Makefile.inc > =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/sys/boot/powerpc/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/uboot/Makefile.inc > =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/sys/boot/uboot/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-18, at 02:38 PM, Mark Millard = wrote: Basic context (more details given later): > # freebsd-version -ku; uname -apKU > 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-NODEBU= G powerpc powerpc64 1100062 1100062 No clang is built or installed. The problem: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc WITHOUT_CLANG_BOOTSTRAP=3D = WITHOUT_CLANG_IS_CC=3D WITHOUT_CLANG=3D WITHOUT_CLANG_EXTRAS=3D = WITHOUT_CLANG_FULL=3D WITHOUT_LLDB=3D WITHOUT_GCC_BOOTSTRAP=3D = WITHOUT_GCC=3D buildworld buildkernel KERNCONF=3DGENERIC64vtsc-NODEBUG = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 processes up to: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -ffreestanding = -msoft-float -Os -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../common = -I/usr/srcC/sys/boot/powerpc/boot1.chrp/../../../ -D_STANDALONE=20 > -m32 -mcpu=3Dpowerpc -m32 -mcpu=3Dpowerpc -std=3Dgnu99 -nostdlib = -static -Wl,-N -m elf32ppc_fbsd -m elf32ppc_fbsd -o boot1.elf boot1.o = ashldi3.o syncicache.o -L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ and then gets for the above command... > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: elf32ppc_fbsd: No such file = or directory > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' > powerpc64-portbld-freebsd11.0-gcc: error: unrecognized command line = option '-m' >=20 > *** [boot1.elf] Error code 1 >=20 > make[6]: stopped in /usr/srcC/sys/boot/powerpc/boot1.chrp > 1 error The -m options seems to be from the likes of... > # $FreeBSD: head/sys/boot/powerpc/Makefile.inc 227739 2011-11-19 = 19:25:57Z andreast $ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > LDFLAGS+=3D -m elf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" and (extracted from using find ... -print): > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/ofw/Makefile.inc > LDFLAGS+=3D -m elf32ppc_fbsd > /usr/srcC/sys/boot/uboot/Makefile.inc > LD=3D"${LD} -m elf32ppc_fbsd" > /usr/srcC/Makefile.inc1 When I looked at "man gcc" I did not find any "-m text" options = or any -melf32ppc_fbsd option. It would suggest that "-m elf32ppc_fbsd" = is not normally valid --matching the complaints by = powerpc64-portbld-freebsd11.0-gcc. Is there a FreeBSD-specific addition to gcc missing in powerpc64-gcc? Context details: WITHOUT_CLANG=3D (bootstrap too) is important to getting this far in my = context. (It was in the make command shown earlier.) # more /etc/src.conf CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ NO_WERROR=3D The CC=3D, CXX=3D, CPP=3D assignments matching the XCC, XCXX, and XCPP = assignments for CROSS_TOOLCHAIN=3Dpowerpc64-gcc are important to getting = this far: otherwise gcc 4.2.1 is used for some things. I also listed = CROSS_BINUTILS_PREFIX and X_COMPILER_TYPE when I added the assignments. = I do not know if they are needed. libc++ include and library path handling did not automatically work so I = added the explicit CXXFLAGS+=3D and LDADD+=3D. If there had been a CXX = specific LDADDCXX I would have used it instead. NO_WERROR=3D is for avoiding stopping for the warnings: I'm not trying = to clean up the status relative to compiler warnings. # svnlite info /usr/srcC/ Path: /usr/srcC Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/Makefile M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h needed an internal friend status established across = typename parameters in order to compile. I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. I build without ps3 in order to allow having both vt = and sc in the build. # ls -FPal /usr/local/include/iconv* -rw-r--r-- 1 root wheel 9348 Mar 12 02:47 = /usr/local/include/iconv.h_alt powerpc64-gcc automatically finds files in /usr/local/include/ such that = they can be used when others with different content but the same name = are appropriate. I renamed /usr/local/include/iconv.h to avoid it being = an example of that. I will not list how I got powerpc64-xtoolchain-gcc (and so = powerpc64-gcc) to finish installing on a powerpc64 11.0-CURRENT. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 19 04:29:03 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F969B43 for ; Thu, 19 Mar 2015 04:29:03 +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 1BB46FDC for ; Thu, 19 Mar 2015 04:29:02 +0000 (UTC) Received: (qmail 30947 invoked from network); 19 Mar 2015 04:29:01 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 04:29:01 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 19 Mar 2015 00:29:01 -0400 (EDT) Received: (qmail 25187 invoked from network); 19 Mar 2015 04:29:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 04:29:00 -0000 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 BBB011C439E; Wed, 18 Mar 2015 21:28:53 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: On using powerpc64-xtoolchain-gcc for buildworld buildkernel on a powerpc64 11.0-CURRENT -r279514 variant Date: Wed, 18 Mar 2015 21:28:58 -0700 Message-Id: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net> To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org 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: Thu, 19 Mar 2015 04:29:03 -0000 Basic starting context: > # freebsd-version -ku; uname -apKU > 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-NODEBU= G powerpc powerpc64 1100062 1100062 No clang present to start with: I did delete-old at the end of the = 10.1-STABLE -> 11.0-CURRENT upgrade before realizing I'd end up with no = clang at all and no direct way to build it. No initial clang means no initial C++11 library either. (Beyond gcc = 4.2.1's range of coverage.) I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. So it is not a strict -r279514 build. So for CROSS_TOOLCHAIN=3Dpowerpc64-gcc how much was I able to include in = buildworld buildkernel (I've not tried including gcc yet)? Well doing... > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 using the context... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D completed buildworld buildkernel. I have not tried installkernel nor installworld yet. WITH_BOOT=3D and = WITH_LIB32=3D materials would be missing or come from other types of = builds that I've done. Unfortunately there is more to getting the above to work then just the = above. Also the below includes notes about why various things are as = they are above. Various oddities need to be avoided/sidestepped for = CROSS_TOOLCHAIN=3Dpowerpc64-gcc use... The first oddity is that on a powerpc64 11.0-CURRENT = powerpc64-xtoolchain-gcc fails to complete its installation because = powerpc64-gcc fails to complete its installation. The powerpc64-gcc = installation problems do not happen on powerpc (non-64) 11.0-CURRENT but = do happen on powerpc64, suggesting TARGET !=3D TARGET_ARCH handling = issues for the port. The problems were 4 mismatched file names and one = file also not put into staging. I copied appropriate files to the = missing names and place and from that status the installation was able = to continue and complete. buildworld attempts to use clang's then-non-existent table generation = programs if WITH_CLANG=3D was used: So I used... WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_LLDB=3D "-m elf32pcc_fbsd" and -melf32pcc_fbsd were not supported on the command = line for powerpc64-gcc: I did not try to change things so that gcc 4.2.1 = would be used just for WITH_LIB32=3D and WITH_BOOT=3D. I was just trying = to figure what and how I can use powerpc64-xtools --and where I can not = currently do so. So I used... WITHOUT_BOOT=3D WITHOUT_LIB32=3D powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. I needed to have head's lib/libnv/test/dnv_tests.cc and = lib/libnv/test/nv_tests.cc from -r279760 or later in order to remove = ambiguous overload issues. > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 When CROSS_TOOLCHAIN=3D..., XCC=3D..., XCXX=3D..., XCPP=3D... are in use = various build stages do not use those but instead use the original = CC=3D..., CXX=3D..., CPP=3D... (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). So I used /etc/src.conf = to force those last 3 assignments to globally be the same as the X... = assignments that CROSS_TOOLCHAIN=3Dpowerpc64-gcc uses: > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D and I listed the other two assignments that = CROSS_TOOLCHAIN=3Dpowerpc64-gcc picks up. (I do not know that it was = necessary to do so.) Looking up the libc++ headers and library did not work automatically so = I added the CXXFLAGS+=3D... and LDADD+=3D... into /etc/src.conf as = indicated above. If there had been a LDADDCXX available I would have = used it instead of LDADD. NO_WERROR=3D was used to avoid stopping at various warnings. I choose to use: WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D but there was no specific problem that prompted me to do that. I do not = yet know how well it would work if gcc was built. Other points learned in the process... As noted above "-m elf32ppc_fbsd" was not allowed by powerpc64-gcc (gcc = 4.9.1): it may not allow the space for -m in general. So I tied the = below but they were also rejected (in a different way)... (I only used = elf32ppc_fbsd contexts.) > # svnlite diff /usr/srcC/Makefile.inc1 /usr/srcC/sys/boot | more > Index: /usr/srcC/Makefile.inc1 > =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/Makefile.inc1 (revision 279514) > +++ /usr/srcC/Makefile.inc1 (working copy) > @@ -396,7 +396,7 @@ > MACHINE_CPU=3D"i686 mmx sse sse2" > LIB32WMAKEFLAGS=3D \ > AS=3D"${AS} --32" \ > - LD=3D"${LD} -m elf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > + LD=3D"${LD} -melf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > =20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" > .if empty(TARGET_CPUTYPE) > @@ -406,7 +406,7 @@ > .endif > LIB32WMAKEENV=3D MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc > LIB32WMAKEFLAGS=3D \ > - LD=3D"${LD} -m elf32ppc_fbsd" > + LD=3D"${LD} -melf32ppc_fbsd" > .endif > =20 > =20 > Index: /usr/srcC/sys/boot/i386/Makefile.inc > =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/sys/boot/i386/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/i386/Makefile.inc (working copy) > @@ -14,7 +14,7 @@ > CFLAGS+=3D -m32 > ACFLAGS+=3D -m32 > # LD_FLAGS is passed directly to ${LD}, not via ${CC}: > -LD_FLAGS+=3D -m elf_i386_fbsd > +LD_FLAGS+=3D -melf_i386_fbsd > AFLAGS+=3D --32 > .endif > =20 > Index: /usr/srcC/sys/boot/ofw/Makefile.inc > =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/sys/boot/ofw/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/powerpc/Makefile.inc > =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/sys/boot/powerpc/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/uboot/Makefile.inc > =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/sys/boot/uboot/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ > =20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif > =20 > .include "../Makefile.inc" I did experiment with compiles of clang some and one thing that I = discovered was: The following file needed to be updated to be language compliant: > # svnlite diff = /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > Index: /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > =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/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (revision 279514) > +++ /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (working copy) > @@ -155,7 +155,7 @@ > =20 > template > IntrusiveRefCntPtr(IntrusiveRefCntPtr&& S) : Obj(S.get()) { > - S.Obj =3D 0; > + S.Obj =3D 0; /* access to private member needs friendship */ > } > =20 > template > @@ -197,6 +197,10 @@ > private: > void retain() { if (Obj) IntrusiveRefCntPtrInfo::retain(Obj); = } > void release() { if (Obj) = IntrusiveRefCntPtrInfo::release(Obj); } > + > +/* FIX for Obj private access issue */ > + template > + friend class IntrusiveRefCntPtr; > }; > =20 > template Upstream llvm has this sort of change already, not with the comments. Other context details: My list of what files are different than svn is: # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S But IntrusiveRefCntPtr.h does not matter if clang building is not = involved. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later than the rest of the unmodified source code, teh rest being = from... # svnlite info /usr/srcC/ Path: . Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # more /etc/make.conf #CPP=3D/usr/local/bin/clang-cpp36 #CC=3D/usr/local/bin/clang36 #CXX=3D/usr/local/bin/clang++36 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 19 09:26:40 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 40C5BA4 for ; Thu, 19 Mar 2015 09:26:40 +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 E578719C for ; Thu, 19 Mar 2015 09:26:39 +0000 (UTC) Received: (qmail 24595 invoked from network); 19 Mar 2015 09:26:38 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 09:26:38 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 19 Mar 2015 05:26:38 -0400 (EDT) Received: (qmail 26741 invoked from network); 19 Mar 2015 09:26:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 09:26:38 -0000 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 591111C43A6; Thu, 19 Mar 2015 02:26:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: On using powerpc64-xtoolchain-gcc for buildworld buildkernel on a powerpc64 11.0-CURRENT -r279514 variant From: Mark Millard In-Reply-To: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net> Date: Thu, 19 Mar 2015 02:26:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0273C21A-C8BD-4D67-9A2B-E4C9938148AF@dsl-only.net> References: <4B4B5E10-43B5-4993-AE45-E23CBC22030B@dsl-only.net> To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org 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: Thu, 19 Mar 2015 09:26:40 -0000 After the previously described buildworld/buildkernel sequence: installkernel then shutdown -r now and so-far-so-good after the reboot installworld then shutdown -r now and so-far-so-good after the reboot delete-old and delete-libs then shutdown -r now and still good after the = reboot $ dmesg -a | head ... FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 ... Of course this is in part based on prior boot1.elf establishment on the = media (WITHOUT_BOOT=3D) and it lacks lib32 (WITHOUT_LIB32=3D) --at least = once I had delete-old and delete-old-libs delete things. (The delete-old and delete-old-libs may have made doing another = buildworld buildkernel a mess since I did not set up for keeping gcc = 4.2.1 related things as active generally. libstdc++ is gone, for = example. I'm not sure legacy will build without libstdc++ and libstdc++ = may well not be automatically regenerated. But I wanted to check on the = lack of old context still being okay for booting and basic operation. I = can always go back and duplicate my paranoia-copy from just before = installkernel.) Also I forgot to mention in the oddities section: establishing libcxxrt = and libc++... I needed to get libcxxrt and libc++ in place before buildworld = buildkernel but after powerpc64-xtoolchain-gcc was installed, using a = context something like... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > #CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > #LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D If I remember right a summary would be... cd /usr/srcC/lib/libcxxrt/; make; make install cd /usr/srcC/lib/libc++/; make; make install in that order. These are what established some context for using > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ in /etc/src.conf during buildworld/buildkernel, unless I misremembering = something. Now that the rebuilds are installed and running the appropriate paths = are different: > CXXFLAGS+=3D-I/usr/include/c++/v1 > LDADD+=3D-L/usr/lib -lc++ =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-18, at 09:28 PM, Mark Millard = wrote: Basic starting context: > # freebsd-version -ku; uname -apKU > 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-NODEBU= G powerpc powerpc64 1100062 1100062 No clang present to start with: I did delete-old at the end of the = 10.1-STABLE -> 11.0-CURRENT upgrade before realizing I'd end up with no = clang at all and no direct way to build it. No initial clang means no initial C++11 library either. (Beyond gcc = 4.2.1's range of coverage.) I have a PowerMac G5 specific change to make booting reliable and some = changes for getting information from early boot failures in case I get = any more of them. So it is not a strict -r279514 build. So for CROSS_TOOLCHAIN=3Dpowerpc64-gcc how much was I able to include in = buildworld buildkernel (I've not tried including gcc yet)? Well doing... > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 using the context... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D completed buildworld buildkernel. I have not tried installkernel nor installworld yet. WITH_BOOT=3D and = WITH_LIB32=3D materials would be missing or come from other types of = builds that I've done. Unfortunately there is more to getting the above to work then just the = above. Also the below includes notes about why various things are as = they are above. Various oddities need to be avoided/sidestepped for = CROSS_TOOLCHAIN=3Dpowerpc64-gcc use... The first oddity is that on a powerpc64 11.0-CURRENT = powerpc64-xtoolchain-gcc fails to complete its installation because = powerpc64-gcc fails to complete its installation. The powerpc64-gcc = installation problems do not happen on powerpc (non-64) 11.0-CURRENT but = do happen on powerpc64, suggesting TARGET !=3D TARGET_ARCH handling = issues for the port. The problems were 4 mismatched file names and one = file also not put into staging. I copied appropriate files to the = missing names and place and from that status the installation was able = to continue and complete. buildworld attempts to use clang's then-non-existent table generation = programs if WITH_CLANG=3D was used: So I used... WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_LLDB=3D "-m elf32pcc_fbsd" and -melf32pcc_fbsd were not supported on the command = line for powerpc64-gcc: I did not try to change things so that gcc 4.2.1 = would be used just for WITH_LIB32=3D and WITH_BOOT=3D. I was just trying = to figure what and how I can use powerpc64-xtools --and where I can not = currently do so. So I used... WITHOUT_BOOT=3D WITHOUT_LIB32=3D powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. I needed to have head's lib/libnv/test/dnv_tests.cc and = lib/libnv/test/nv_tests.cc from -r279760 or later in order to remove = ambiguous overload issues. > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 When CROSS_TOOLCHAIN=3D..., XCC=3D..., XCXX=3D..., XCPP=3D... are in use = various build stages do not use those but instead use the original = CC=3D..., CXX=3D..., CPP=3D... (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). So I used /etc/src.conf = to force those last 3 assignments to globally be the same as the X... = assignments that CROSS_TOOLCHAIN=3Dpowerpc64-gcc uses: > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 > LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ > NO_WERROR=3D and I listed the other two assignments that = CROSS_TOOLCHAIN=3Dpowerpc64-gcc picks up. (I do not know that it was = necessary to do so.) Looking up the libc++ headers and library did not work automatically so = I added the CXXFLAGS+=3D... and LDADD+=3D... into /etc/src.conf as = indicated above. If there had been a LDADDCXX available I would have = used it instead of LDADD. NO_WERROR=3D was used to avoid stopping at various warnings. I choose to use: WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D but there was no specific problem that prompted me to do that. I do not = yet know how well it would work if gcc was built. Other points learned in the process... As noted above "-m elf32ppc_fbsd" was not allowed by powerpc64-gcc (gcc = 4.9.1): it may not allow the space for -m in general. So I tied the = below but they were also rejected (in a different way)... (I only used = elf32ppc_fbsd contexts.) > # svnlite diff /usr/srcC/Makefile.inc1 /usr/srcC/sys/boot | more > Index: /usr/srcC/Makefile.inc1 > =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/Makefile.inc1 (revision 279514) > +++ /usr/srcC/Makefile.inc1 (working copy) > @@ -396,7 +396,7 @@ > MACHINE_CPU=3D"i686 mmx sse sse2" > LIB32WMAKEFLAGS=3D \ > AS=3D"${AS} --32" \ > - LD=3D"${LD} -m elf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" > + LD=3D"${LD} -melf_i386_fbsd -Y = P,${LIB32TMP}/usr/lib32" >=20 > .elif ${TARGET_ARCH} =3D=3D "powerpc64" > .if empty(TARGET_CPUTYPE) > @@ -406,7 +406,7 @@ > .endif > LIB32WMAKEENV=3D MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc > LIB32WMAKEFLAGS=3D \ > - LD=3D"${LD} -m elf32ppc_fbsd" > + LD=3D"${LD} -melf32ppc_fbsd" > .endif >=20 >=20 > Index: /usr/srcC/sys/boot/i386/Makefile.inc > =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/sys/boot/i386/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/i386/Makefile.inc (working copy) > @@ -14,7 +14,7 @@ > CFLAGS+=3D -m32 > ACFLAGS+=3D -m32 > # LD_FLAGS is passed directly to ${LD}, not via ${CC}: > -LD_FLAGS+=3D -m elf_i386_fbsd > +LD_FLAGS+=3D -melf_i386_fbsd > AFLAGS+=3D --32 > .endif >=20 > Index: /usr/srcC/sys/boot/ofw/Makefile.inc > =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/sys/boot/ofw/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/ofw/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/powerpc/Makefile.inc > =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/sys/boot/powerpc/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/powerpc/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" > Index: /usr/srcC/sys/boot/uboot/Makefile.inc > =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/sys/boot/uboot/Makefile.inc (revision 279514) > +++ /usr/srcC/sys/boot/uboot/Makefile.inc (working copy) > @@ -2,7 +2,7 @@ >=20 > .if ${MACHINE_ARCH} =3D=3D "powerpc64" > CFLAGS+=3D -m32 -mcpu=3Dpowerpc > -LDFLAGS+=3D -m elf32ppc_fbsd > +LDFLAGS+=3D -melf32ppc_fbsd > .endif >=20 > .include "../Makefile.inc" I did experiment with compiles of clang some and one thing that I = discovered was: The following file needed to be updated to be language compliant: > # svnlite diff = /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > Index: /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > =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/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (revision 279514) > +++ /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h = (working copy) > @@ -155,7 +155,7 @@ >=20 > template > IntrusiveRefCntPtr(IntrusiveRefCntPtr&& S) : Obj(S.get()) { > - S.Obj =3D 0; > + S.Obj =3D 0; /* access to private member needs friendship */ > } >=20 > template > @@ -197,6 +197,10 @@ > private: > void retain() { if (Obj) IntrusiveRefCntPtrInfo::retain(Obj); } > void release() { if (Obj) IntrusiveRefCntPtrInfo::release(Obj); = } > + > +/* FIX for Obj private access issue */ > + template > + friend class IntrusiveRefCntPtr; > }; >=20 > template Upstream llvm has this sort of change already, not with the comments. Other context details: My list of what files are different than svn is: # svnlite status /usr/srcC/ --no-ignore ? /usr/srcC/.snap M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h ? /usr/srcC/restoresymtable M /usr/srcC/sys/ddb/db_main.c M /usr/srcC/sys/ddb/db_script.c ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/srcC/sys/powerpc/conf/GENERICvtsc ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c M /usr/srcC/sys/powerpc/ofw/ofwcall64.S But IntrusiveRefCntPtr.h does not matter if clang building is not = involved. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later than the rest of the unmodified source code, teh rest being = from... # svnlite info /usr/srcC/ Path: . Working Copy Root Path: /usr/srcC URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279514 Node Kind: directory Schedule: normal Last Changed Author: adrian Last Changed Rev: 279514 Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) # more /etc/make.conf #CPP=3D/usr/local/bin/clang-cpp36 #CC=3D/usr/local/bin/clang36 #CXX=3D/usr/local/bin/clang++36 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 19 12:13:06 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18947BDD for ; Thu, 19 Mar 2015 12:13:06 +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 B2F5787D for ; Thu, 19 Mar 2015 12:13:05 +0000 (UTC) Received: (qmail 20755 invoked from network); 19 Mar 2015 12:13:03 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Mar 2015 12:13:03 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 19 Mar 2015 08:13:03 -0400 (EDT) Received: (qmail 17926 invoked from network); 19 Mar 2015 12:13:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Mar 2015 12:13:03 -0000 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 380A81C43AA; Thu, 19 Mar 2015 05:13:01 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: lib/csu/powerpc64/ requires/uses gcc command; does not use CC, XCC, or the like; its Makefile explains what caused the choice... Date: Thu, 19 Mar 2015 05:13:01 -0700 Message-Id: To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org 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: Thu, 19 Mar 2015 12:13:06 -0000 For a CROSS_TOOLCHAIN=3Dpowerpc64-gcc based 11.0-CURRENT previously = built via WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D and for which = delete-old had cleaned out the 4.2.1 gcc and for which a rebuild is = attempted with... make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ WITHOUT_LLDB=3D \ WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITH_GNUCXX=3D \ WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ buildworld buildkernel \ KERNCONF=3DGENERIC64vtsc-NODEBUG \ TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 using... # more /etc/src.conf CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc CXXFLAGS+=3D-I/usr/include/c++/v1 LDADD+=3D-L/usr/lib -lc++ NO_WERROR=3D It turns out that lib/csu/powerpc64/ still tries to use the gcc command: CC=3D'gcc -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1' mkdep -f .depend = -a -I/usr/srcC/lib/csu/powerpc64/../common = -I/usr/srcC/lib/csu/powerpc64/../../libc/include -std=3Dgnu99 = /usr/srcC/lib/csu/powerpc64/crt1.c /usr/srcC/lib/csu/powerpc64/crti.S = /usr/srcC/lib/csu/powerpc64/crtn.S ... /usr/bin/mkdep: gcc: not found That stops the build. lib/csu/powerpc64/Makefile reports... # XXX: See the log for r232932 as to why the above -mlongcall is needed. = Since # clang doesn't support -mlongcall, and testing shows a clang linked = with a # clang-built csu segfaults, this must currently be compiled with gcc. = Once # clang supports -mlongcall, or we get a fixed ld, this can be = revisited. CC:=3D gcc COMPILER_TYPE:=3D gcc So this lead to another after-booted-as-gcc-4.9.1-based type of = oddity... Currently I'm having /usr/bin/gcc and /usr/bin/g++ be manually placed = symbolic links to the powerpc64-gcc programs, much like I've directed = /usr/lib/libstdc++.a and /usr/lib/libstdc++.so to reference the matching = libc++ file in the same directory in order to avoid complaints about not = finding -lstdc++ when I attempt the above make command. I've noticed that /usr/bin/cc and /usr/bin/c++ are still there for the = powerpc64-gcc experimental sequence that I've gone through and they are = still gcc 4.2.1. So I could point gcc and g++ to those to better match = the old context. But I'm exploring avoiding gcc 4.2.1 as much as I = reasonably can. I'm still avoiding building clang because a quick try got lost of error = reports, such as reports of attempts to use deleted functions. That = would seem to make an independent exploration direction. For now I'm = just checking on having a way to rebuild again but from the = powerpc64-gcc (4.9.1) build, this time including WITH_GCC_BOOTSTRAP=3D = and WITH_GCC=3D and WITH_GNUCXX=3D but avoiding their use. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 20 20:10:55 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 91F0F592; Fri, 20 Mar 2015 20:10:55 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 091102E9; Fri, 20 Mar 2015 20:10:52 +0000 (UTC) Received: by lbblx11 with SMTP id lx11so61076738lbb.3; Fri, 20 Mar 2015 13:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=Hmwn89o7tyzI60HN6R4LpecfqeYpWuZXsI6HAvfeE5M=; b=Cx3cN7DQlietDdNO4JI5XW17Su/E+I37ho9Tw2hq0DF7EZ4PhOhJoJTAlkFfiLQDnw s1ASuxOuE3HEkfmW7p/IZA6esF8ys2otoVEbmhOYttbWbpImXjvAHoQ1DyphJ7aGf8Ew 6rCxFmX+Lq4ELFevfJoiUrOtXHxhE7M/nRDOGC7ljwAr2tbkmIanO981mKGyYAn8ESiU +Yx7rTvO2p7QPBpHg29Vf/0zoVznsg83HZsRkfuLAJfY/NWfOgImJEwu0H9qV6hwDcOY MljLnqp0r0pm5w3wkxkvlUUOOybqKT1hZ855orzPuv7PdgKsplFXm3PdxdZiPjsX7iKk zuYw== MIME-Version: 1.0 X-Received: by 10.112.26.209 with SMTP id n17mr68890925lbg.84.1426882249958; Fri, 20 Mar 2015 13:10:49 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Fri, 20 Mar 2015 13:10:49 -0700 (PDT) Date: Fri, 20 Mar 2015 13:10:49 -0700 X-Google-Sender-Auth: UViZ9lM-oQyOKt1l2GFqCCEFCPI Message-ID: Subject: External toolchain build failing due to missing --sysroot From: Craig Rodrigues To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: George Neville-Neil , freebsd-toolchain@freebsd.org, "freebsd-testing@freebsd.org" 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: Fri, 20 Mar 2015 20:10:55 -0000 Warner, I can't get the external toolchain build of CURRENT to work, because --sysroot seems to be missing in some places. See: https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001452.html gnn@ said you might know where this can be fixed. Any idea of a patch that can fix this? -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 20 21:17:37 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08183BD for ; Fri, 20 Mar 2015 21:17:37 +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 B41ACD28 for ; Fri, 20 Mar 2015 21:17:35 +0000 (UTC) Received: (qmail 19632 invoked from network); 20 Mar 2015 21:17:29 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Mar 2015 21:17:29 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 20 Mar 2015 17:17:29 -0400 (EDT) Received: (qmail 10081 invoked from network); 20 Mar 2015 21:17:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Mar 2015 21:17:28 -0000 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 CB0301C43AE; Fri, 20 Mar 2015 14:17:23 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc: -pg compile gets ../libcxxrt/terminate.cc:36:7: internal compiler error: Segmentation fault Date: Fri, 20 Mar 2015 14:17:26 -0700 Message-Id: To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@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: Fri, 20 Mar 2015 21:17:37 -0000 It turns out that I had to rebuild powerpc64-gcc after booting into the = powerpc64-gcc based installed world (and kernel). The below notes start = from before that rebuild of powerpc64-gcc. Basic context (more detail later): > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (So this is was bootstrapped via a buildworld buildkernel with = CROSS_TOOLSCHAIN=3Dpowerpc64-gcc involved.) > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 WITHOUT_BOOT=3D and WITHOUT=3DLIB32=3D were used for the above build. Also WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D . And WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D = WITHOUT_LLDB=3D . > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > WITH_LIBCPLUSPLUS=3D > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=3Dgnu+=3D11 = -L/usr/obj/usr/srcC/lib/libc++ > NO_WERROR=3D The active build with the compiler crash was working on: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 in the above context. But it turns out that I can show the problem in a = much quicker form then waiting for the rebuild to get to that point. The problem: For the quicker form of test: having done buildworld buildkernel from = the gcc 4.2.1 based powerpc64 SSD but using powerpc64-gcc via = CROSS_TOOLCHAIN=3Dpowerpc64-gcc (much like the above)... installworld (and installkernel) to another SSD that is effectively = initially a copy of the gcc 4.2.1 based one with the powerpc64-gcc = present. Then reboot into that newer SSD. Using the above /etc/src.conf = then try something like: > mkdir -p /tmp/lib \ > && mkdir -p /tmp/usr/lib \ > && mkdir -p /tmp/usr/srcC/lib/libcxxrt \ > && cd /usr/srcC/lib/libcxxrt/ \ > && MAKEOBJDIRPREFIX=3D/tmp \ > make CROSS_TOOLCHAIN=3Dpowerpc64-gcc DIRPRFX=3Dlib/libcxxrt/ = DESTDIR=3D/tmp obj depend all install The point being to get the involved .cc files to be compiled in the = normal way, including in the form that uses -pg. This which works fine on the original SSD (given that SSD's = /etc/src.conf that uses = CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 and = LDADD+=3D-L/usr/obj/usr/srcC/usr/lib/libc++ -lc++ ). The result for -pg for contrib/libcxxrt/terminate.cc on the gcc 4.9.1 = based SSD was consistently: > /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc: In = function 'void std::terminate()': > /usr/srcC/lib/libcxxrt/../../contrib/libcxxrt/terminate.cc:36:7: = internal compiler error: Segmentation fault > void terminate() > ^ > no stack trace because unwind library not available > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** [terminate.po] Error code 1 >=20 > make[4]: stopped in /usr/srcC/lib/libcxxrt > 1 error >=20 > make[4]: stopped in /usr/srcC/lib/libcxxrt > *** [all_subdir_libcxxrt] Error code 2 Rebuilding powerpc64-gcc from the booted powerpc64-gcc based SSD (in my = case via gcc5 use and portmaster) and trying again shows that the = rebuild has removed the above crash status for -pg use. (Until the powerpc64-gcc port avoids failing for file name/placement = problems when used on powerpc64's, having powerpc64-gcc rebuild itself = in such a context is a no-go: It fails between removing itself and = putting back the newer materials. That does not leave enough materials = around for a portmaster with -C to continue after a hand adjusted group = of file names/placements.) There appears to be some form of binary incompatibility for -pg that = requires the powerpc64-gcc rebuild to get the new binary context right. = Once it matches it seems fine. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 -std=3Dgnu+=3D11 = -L/usr/obj/usr/srcC/lib/libc++ is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1 in CXXFLAGS and = the like. This is despite the /usr/srcC/Makefile.inc1 logic (that ends = up inactive for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > #CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > #CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > #X_COMPILER_TYPE=3Dgcc > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during buildworld/buildkernel activity. > # See /etc/src.conf for example buildworld/buildkernel values. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 21 01:04:57 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 AD6F885E for ; Sat, 21 Mar 2015 01:04:57 +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 65C6691D for ; Sat, 21 Mar 2015 01:04:56 +0000 (UTC) Received: (qmail 27151 invoked from network); 21 Mar 2015 01:04:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Mar 2015 01:04:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 20 Mar 2015 21:04:55 -0400 (EDT) Received: (qmail 8956 invoked from network); 21 Mar 2015 01:04:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Mar 2015 01:04:55 -0000 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 4D7FF1C439E; Fri, 20 Mar 2015 18:04:49 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 11.0-CURRENT CROSS_TOOLSCHAIN=powerpc64-gcc when building with WITH_CLANG= defined: include/c++/v1/ problems... Date: Fri, 20 Mar 2015 18:04:53 -0700 Message-Id: To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@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: Sat, 21 Mar 2015 01:04:57 -0000 CROSS_TOOLCHAIN=3Dpowerpc64-gcc will not automatically use = /usr/include/c++/v1/ paths or /usr/lib/ paths. And those paths are only = appropriate sometimes. Other times paths such as = /usr/obj/usr/srcC/tmp/usr/include/c++/v1 and = /usr/obj/usr/srcC/lib/libc++ are appropriate.=20 The later material concludes that = _bootstrap-tools-lib/clang/libllvmtablegen and the like do not have a = well controlled c++ header/library(?) environment for = CROSS_TOOLCHAIN=3D... use. /etc/src.conf lines such as: > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. are a problem in general. So far I've not found a good hook for making = the distinctions for CROSS_TOOLSCHAIN=3Dpowerpc64-gcc : > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/.=20 > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a CROSS_TOOLSCHAIN=3D... like manor = sometimes having both can work. Note: My context happens to be self-hosting: powerpc64 using = CROSS_TOOLCHAIN=3Dpowerpc64-gcc. I've taken advantage of that status in = the details of what I've done but I do not know what I'd do in a true = non-self-hosting context. Even for WITHOUT_CLANG=3D I've used > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/.=20 in /etc/src.conf because, for example, without it atf-c++ ended up = with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. This without-ostream case was despite the /usr/srcC/Makefile.inc1 logic = (that ends up inactive/ineffective for some reason at the time): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 Basic context (more detail later): > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... (So this is was bootstrapped via a buildworld buildkernel with = CROSS_TOOLSCHAIN=3Dpowerpc64-gcc involved.) > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 WITHOUT_BOOT=3D and WITHOUT=3DLIB32=3D were used for the above build. Also WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D . And WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D = WITHOUT_LLDB=3D . > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > WITH_LIBCPLUSPLUS=3D > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place depends on = self-hodsting > # where the two are sufficient compatibile. > # > # I've used .../. paths so I can tell use of these from other sources = of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/.=20 > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > #CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross-tools like manor sometimes having = both can work. > # > NO_WERROR=3D was used as context for: > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 The problem: Without the /etc/src.conf line (or equivalent): > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. when I turned on WITH_CLANG=3D (see above) in order to try to build = clang during buildworld it got... > --- _bootstrap-tools-lib/clang/libllvmtablegen --- > CC=3D'/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc ' mkdep -f = .depend -a = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib > /llvm/tools/clang/include = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen = -I. = -I/usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clan= g/include -DLLVM_ON_UNI > X -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT > =3D\"\" -I/usr/obj/usr/srcC/tmp/legacy/usr/include = -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 -std=3Dc++11 = = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Err= or.c > pp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Mai= n.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Rec= ord.cpp /usr/srcC/lib/clang/libllvmtablegen > /../../../contrib/llvm/lib/TableGen/SetTheory.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Str= ingMatcher.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib > /TableGen/TableGenBackend.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGL= exer.cpp = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/TGP= arser.cpp=20 > In file included from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT= /SmallVector.h:17:0, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT= /ArrayRef.h:14, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/Sup= port/SourceMgr.h:19, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/Tab= leGen/Error.h:18, > from = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Err= or.cpp:15: > = /usr/srcC/lib/clang/libllvmtablegen/../../../contrib/llvm/include/llvm/ADT= /iterator_range.h:22:19: fatal error: utility: No such file or directory > #include > ^ > compilation terminated. Removing > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. from /etc/src.conf does not make the c++11 headers available at that = time. Only adding something like: > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. did. (Luckily for what I'd doing having both CXXFLAGS+=3D... works out = okay.) I did not notice anything that suggested an intended way to deal with = the two contexts for CROSS_TOOLCHAIN=3Dpowerpc64-gcc use. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. CROSS_TOOLCHAIN=3Dpowerpc64-gcc use does not allow -melf32ppc_fbsd for = WITH_BOOT=3D and WITH_LIB32=3D build activity to use. Even if there was = a powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing = just the WITH_BOOT=3D and WITH_LIB32=3D would still not seem a natural = fit. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). Originally I was = investigating how far I could get without involving gcc 4.2.1 and what = would be involved. In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. in CXXFLAGS = and the like. This is despite the /usr/srcC/Makefile.inc1 logic (that = ends up inactive/ineffective for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > #CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > #CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > #X_COMPILER_TYPE=3Dgcc > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during the buildworld/buildkernel activities: > # _includes _libraries _depend everything build32. > # See /etc/src.conf for example buildworld/buildkernel > # values for that context. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc from a booted world that had been built = based on powerpc64-gcc in a gcc 4.2.1 world.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I've made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 21 06:27:24 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B062CD2 for ; Sat, 21 Mar 2015 06:27:24 +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 03828BF4 for ; Sat, 21 Mar 2015 06:27:23 +0000 (UTC) Received: (qmail 29416 invoked from network); 21 Mar 2015 06:27:21 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Mar 2015 06:27:21 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 21 Mar 2015 02:27:21 -0400 (EDT) Received: (qmail 22345 invoked from network); 21 Mar 2015 06:27:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Mar 2015 06:27:21 -0000 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 A99191C439E; Fri, 20 Mar 2015 23:27:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: CROSS_TOOLCHAIN=powerpc64-gcc mishandles "Substitution Failure Is Not An Error" when compiling clang and stops the build Date: Fri, 20 Mar 2015 23:27:19 -0700 Message-Id: <52182692-C48C-4438-8AF1-318828E8F966@dsl-only.net> To: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@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: Sat, 21 Mar 2015 06:27:24 -0000 Basic context: > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 18 20:11:15 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 For the context set by: > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > WITH_LIBCPLUSPLUS=3D > # > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > # spans being-built and (failing finding those directories) live and = so for > # -DNO_CLEAN after being-built ones are in place depends on = self-hodsting > # where the two are sufficient compatibile. > # > # I've used .../. paths so I can tell use of these from other sources = of paths. > # > # Actually only appropriate for for _includes _libraries _depend = everything build32 : > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++/. > # > # Actually only appropriate for for _worldtmp _legacy _bootstrap-tools = _cleanobj _obj _build-tools _cross-tools : > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. > # > # But for self-hosting in a cross tools like manor sometimes having = both can work. > # > NO_WERROR=3D The problem: (Somewhat reformatted text...) > In file included from /usr/include/c++/v1/./algorithm:625:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringRef.h:13, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:17, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > /usr/include/c++/v1/./type_traits: >=20 > In instantiation of 'struct std::__1::__is_convertible&, = llvm::StringMap, 0u, 0u>': > /usr/include/c++/v1/./type_traits:943:62: > required from >=20 > 'struct std::__1::is_convertible&, = llvm::StringMap >' > /usr/include/c++/v1/./utility:269:77: > required by >=20 > substitution of 'template std::__1::pair<_T1, = _T2>::pair(const std::__1::pair<_U1, _U2>&, typename = std::__1::enable_if<(std::__1::is_convertible::value && = std::__1::is_convertible::value)>::type*) [with _U1 =3D = llvm::StringRef; _U2 =3D llvm::StringMap]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:371:55: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef, = InitTy) [with InitTy =3D llvm::StringMap; = ValueTy =3D llvm::StringMap; AllocatorTy =3D= llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:375:43: > required from >=20 > 'llvm::StringMap::MapEntryTy& = llvm::StringMap::GetOrCreateValue(llvm::StringRef) = [with ValueTy =3D llvm::StringMap; = AllocatorTy =3D llvm::MallocAllocator; llvm::StringMap::MapEntryTy =3D = llvm::StringMapEntry >]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:299:32: > required from >=20 > 'ValueTy& llvm::StringMap::operator[](llvm::StringRef) [with ValueTy =3D = llvm::StringMap; AllocatorTy =3D = llvm::MallocAllocator]' > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:120:21: > required from >=20 > here > /usr/include/c++/v1/./type_traits:881:87: error: use of deleted = function 'llvm::StringMap::StringMap(const = llvm::StringMap&)' > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) =3D=3D 1 > = ^ and a little more... > In file included from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Supp= ort/SpecialCaseList.h:51:0, > from = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Speci= alCaseList.cpp:17: > = /usr/srcC/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/= StringMap.h:226:7: > note: 'llvm::StringMap::StringMap(const = llvm::StringMap&)' is implicitly declared = as deleted because 'llvm::StringMap' = declares a move constructor or move assignment operator > class StringMap : public StringMapImpl { > ^ where... > namespace __is_convertible_imp > { > template char __test(_Tp); > template __two __test(...); > #ifndef _LIBCPP_HAS_NO_RVALUE_REFERENCES > template _Tp&& __source(); > #else =20 > template typename remove_reference<_Tp>::type& __source(); > #endif > =20 > ... > } In other words: > __is_convertible_imp::__source&>() is a function returning llvm::StringMap&& = (an r-value reference, not a universal one). (I'm presuming rvalue = references but the overall point is the same even for const = llvm::StringMap& as the return type.) As for __is_convertible_imp::__test: > = __is_convertible_imp::__test= > > (llvm::StringMap) is a function returning a value of type char that is used when the = argument can be passed into a = llvm::StringMap type of parameter. Failure = of this to be possible is not of itself an error ("substitution failure = is not an error" for selecting template functions): it just means that = other example definitions of __is_convertible_imp::__test functions may = be used to match the argument instead. and > = __is_convertible_imp::__test= >(...) is a function returning a value of type __two for all potential, valid = argument lists. (_T2 is actually ignored.) When both = __is_convertible_imp::__test's are non-errors the prior one is picked by = the language rules: a better parameter vs. argument match. Note that the status of deleted copy constructors can contribute to if > = __is_convertible_imp::__test= > > (llvm::StringMap) is a match for the convertibility classifications and it is not an error = for them to do so. The size of the selected = __is_convertible_imp::__test= >'s result type indicates the is-convertible status (sizeof(char) !=3D = sizeof(__two)) and the sizeof use means that overall the expression is a = constexpr (compile time constant) that is based on the type analysis by = the compiler, with no actual constructions happening. But the powerpc64-gcc 4.9.1 compiler is not applying the principle of = "substitution failure is not an error" and is not using the implicitly = deleted-status to cause a mis-match for: > = __is_convertible_imp::__test= > > (llvm::StringMap) So the compiler rejects the code for supposed use of an implicitly = deleted StringMap(const StringMap &RHS) constructor. This is a wrong = classification for the code. It appears that powerpc64-gcc (gcc 4.9.1) is not up to compiling = 11.0-CURRENT -r279514's clang/llvm as-is. Context details, mostly applying to both gcc 4.2.1 based world/kernel = with powperpc-gcc in use for cross compiling and gcc 4.9.1 based = world/kernel: powerpc64-gcc automatically looks in /usr/local/include for header files = (like most such ports) and this can pick up the wrong file(s). I ended = up renaming /usr/local/include/iconv.h so that it would not be found and used where a file with different = content from my /usr/srcC/... was needed. CROSS_TOOLCHAIN=3Dpowerpc64-gcc use does not allow -melf32ppc_fbsd for = WITH_BOOT=3D and WITH_LIB32=3D build activity to use. Even if there was = a powerpc-xtoolchain-gcc (and powerpc-gcc) around then selectively doing = just the WITH_BOOT=3D and WITH_LIB32=3D would still not seem a natural = fit. In my experiments at times for the 4.9.1 based live-world I've placed = the following symbolic links: > # ls -FPal /usr/lib/libstdc* > lrwxr-xr-x 1 root wheel 8 Mar 19 03:47 /usr/lib/libstdc++.a@ -> = libc++.a > lrwxr-xr-x 1 root wheel 9 Mar 19 03:47 /usr/lib/libstdc++.so@ -> = libc++.so >=20 > # ls -FPal /usr/bin/gcc /usr/bin/g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/g++@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > lrwxr-xr-x 1 root wheel 48 Mar 19 04:20 /usr/bin/gcc@ -> = /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc For example csu/powerpc64/... uses "gcc" directly, ignoring XCC and CC. The CC, CXX, and CPP in... > # more /etc/src.conf > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > ... that essentially duplicate the XCC, XCXX, XCPP assignments from = CROSS_TOOLCHAIN=3Dpowerpc64-gcc are there because otherwise various = stages do not use the cross tools (legacy, bootstrap-tools, build-tools, = cross-tools, kernel-tools, lib32's build-tools). Originally I was = investigating how far I could get without involving gcc 4.2.1 and what = would be involved. In the running world built-via-powerpc64-gcc environment /etc/src.conf = having ... > # CXXFLAGS For buildworld/buildkernel CROSS_TOOLCHAIN=3Dpowerpc64-gcc = use... > CXXFLAGS+=3D-I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. -std=3Dgnu+=3D1= 1 -L/usr/obj/usr/srcC/lib/libc++/. is used because otherwise (for example)... > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -fpic -DPIC -O2 = -pipe -DHAVE_CONFIG_H -I/usr/srcC/contrib/atf = -I/usr/srcC/lib/atf/libatf-c++/../libatf-c -I. -DHAVE_CONFIG_H = -fstack-protector -Wsyste > m-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter = -Wpointer-arith -Wno-uninitialized -c = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp -o application.So ends up with... > In file included from = /usr/srcC/contrib/atf/atf-c++/detail/application.cpp:26:0: > /usr/srcC/contrib/atf/atf-c++/detail/application.hpp:29:19: fatal = error: ostream: No such file or directory > #include > ^ > compilation terminated. from lack of -I/usr/obj/usr/srcC/tmp/usr/include/c++/v1/. in CXXFLAGS = and the like. This is despite the /usr/srcC/Makefile.inc1 logic (that = ends up inactive/ineffective for some reason): > .if ${XCC:M/*} > ... > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} =3D=3D gcc > XCFLAGS+=3D -isystem ${WORLDTMP}/usr/include = -L${WORLDTMP}/usr/lib > XCXXFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 -std=3Dgnu++11 = -L${WORLDTMP}/../lib/libc++ > DEPFLAGS+=3D -I${WORLDTMP}/usr/include/c++/v1 As for /etc/make.conf it looks like... > # more /etc/make.conf > #CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > #CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > #CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > #X_COMPILER_TYPE=3Dgcc > # CXFLAGS For normal powerpc64-gcc use... > # AVOID during the buildworld/buildkernel activities: > # _includes _libraries _depend everything build32. > # See /etc/src.conf for example buildworld/buildkernel > # values for that context. > #CXXFLAGS+=3D-I/usr/include/c++/v1 -std=3Dgnu++11 = -L/usr/obj/usr/srcC/lib/libc++ > # > #CC=3D/usr/local/bin/gcc5 > #CXX=3D/usr/local/bin/g++5 > #CPP=3D/usr/local/bin/cpp5 > #CC=3D/usr/local/bin/clang36 > #CXX=3D/usr/local/bin/clang++36 > #CPP=3D/usr/local/bin/clang-cpp36 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D (Some of the comments show how gcc5/g++5 use was temporarily forced = while rebuilding powerpc64-gcc from a booted world that had been built = based on powerpc64-gcc in a gcc 4.2.1 world.) > # svnlite info /usr/srcC/ > Path: /usr/srcC > Working Copy Root Path: /usr/srcC > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279514 > Node Kind: directory > Schedule: normal > Last Changed Author: adrian > Last Changed Rev: 279514 > Last Changed Date: 2015-03-01 18:27:25 -0800 (Sun, 01 Mar 2015) > # svnlite status /usr/srcC/ --no-ignore > ? /usr/srcC/.snap > M /usr/srcC/contrib/llvm/include/llvm/ADT/IntrusiveRefCntPtr.h > ? /usr/srcC/restoresymtable > M /usr/srcC/sys/ddb/db_main.c > M /usr/srcC/sys/ddb/db_script.c > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc > ? /usr/srcC/sys/powerpc/conf/GENERIC64vtsc-NODEBUG > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc > ? /usr/srcC/sys/powerpc/conf/GENERICvtsc-NODEBUG > M /usr/srcC/sys/powerpc/ofw/ofw_machdep.c > M /usr/srcC/sys/powerpc/ofw/ofwcall64.S IntrusiveRefCntPtr.h does not matter if clang building is not involved. = It needed a friend declaration to gain access to a private field, = otherwise compilation stopped. And the rest existed in my environment before I started this = powerpc64-xtoolchain-gcc exploration. lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from = later (-r279760) than the rest of the unmodified source code. This is in = order to remove ambiguous overload issues. > # svnlite info /usr/ports > Path: /usr/ports > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 381120 > Node Kind: directory > Schedule: normal > Last Changed Author: dbn > Last Changed Rev: 381120 > Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015) I have gcc5 and clang36 ports installed. I've made no use of clang36. On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete = its installation because powerpc64-gcc fails to complete its = installation. The problems were 4 mismatched file names and one file = also not put into staging. I copied appropriate files to the missing = names and place and from that status the installation was able to = continue and complete via postmaster with -C (as long as powerpc64-gcc = was not in use rebuilding itself: some other compiler was in use for = that activity instead). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 21 23:26:08 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 0FFD0A2 for ; Sat, 21 Mar 2015 23:26:08 +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 BDF01A13 for ; Sat, 21 Mar 2015 23:26:06 +0000 (UTC) Received: (qmail 19860 invoked from network); 21 Mar 2015 23:25:59 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Mar 2015 23:25:59 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 21 Mar 2015 19:25:59 -0400 (EDT) Received: (qmail 8914 invoked from network); 21 Mar 2015 23:25:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Mar 2015 23:25:59 -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 E174E1C439E; Sat, 21 Mar 2015 16:25:53 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 context for clang36 use: /usr/bin/ld too old(?) but is used by clang36 Date: Sat, 21 Mar 2015 16:25:56 -0700 Message-Id: <64205C7D-7DF3-44F0-85C2-3C49B4EE0A4C@dsl-only.net> To: freebsd-ports@freebsd.org, Brooks Davis Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) 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: Sat, 21 Mar 2015 23:26:08 -0000 Basic context: [I'm using an example taken from buildworld activity just for = illustration. Yes, I know that powerpc64 buildworld via clang is not yet supported. = buildworld is not the actual point here but does illustrate a = pre-existing build environment having the issue in question.] > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed = Mar 18 20:11:15 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/srcC/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100062 1100062 > # which ld > /usr/bin/ld > # ld --version > GNU ld 2.17.50 [FreeBSD] 2007-07-03 > Copyright 2007 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms = of > the GNU General Public License. This program has absolutely no = warranty. > export PATH=3D"/usr/local/powerpc64-freebsd/bin:$PATH" > make -j 8 \ > WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D \ > WITH_LLDB=3D \ > WITH_GCC_BOOTSTRAP=3D WITH_GCC=3D WITHOUT_GNUCXX=3D \ > WITH_BOOT=3D WITH_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 > # more /etc/src.conf > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > # > # For trying clang36... > # (I'm trying to use binutils from the powerpc64-xtoolchain-gcc = install.) > # > CC=3D/usr/local/bin/clang36 > CXX=3D/usr/local/bin/clang++36 > CPP=3D/usr/local/bin/clang-cpp36 > #CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > AS=3D/usr/local/powerpc64-freebsd/bin/as > AR=3D/usr/local/powerpc64-freebsd/bin/ar > LD=3D/usr/local/powerpc64-freebsd/bin/ld > NM=3D/usr/local/powerpc64-freebsd/bin/nm > OBJCOPY=3D/usr/local/powerpc64-freebsd/bin/objcopy > OBJDUMP=3D/usr/local/powerpc64-freebsd/bin/objdump > RANLIB=3D/usr/local/powerpc64-freebsd/bin/ranlib > SIZE=3D/usr/local/powerpc64-freebsd/bin/size > STRINGS=3D/usr/local/powerpc64-freebsd/bin/strings > XAS=3D${AS} > XAR=3D${AR} > XLD=3D${LD} > XNM=3D${NM} > XOBJCOPY=3D${OBJCOPY} > XOBJDUMP=3D${OBJDUMP} > XRANLIB=3D${RANLIB} > XSIZE=3D${SIZE} > XSTRINGS=3D${STRINGS} ... The problem: When the clang36 driver program is used to (for example) link programs = it apparently automatically and always uses /usr/bin/ld. But for = powerpc64 /usr/bin/ld is BFD 2.17.50 vintage and reports an internal = error (see below). It seems likely that clang36 simply requires more recent binutils = programs, such as from binutils-2.25 currently. > /usr/local/bin/clang36 -O2 -pipe -DHAVE_CONFIG_H = -I/usr/srcC/kerberos5/tools/make-roken/../../include -DHAVE_CONFIG_H = -I/usr/srcC/kerberos5/tools/make-roken/../../include -std=3Dgnu99 = -Qunused-argumen > ts -I/usr/obj/usr/srcC/tmp/legacy/usr/include -static = -L/usr/obj/usr/srcC/tmp/legacy/usr/lib -o make-roken make-roken.o = -legacy > /usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error, aborting = at = /usr/srcC/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf= 64-ppc.c line 11029 in ppc64_elf_relocate_section > /usr/bin/ld: Please report this bug. If the clang36 port allowed binding to binutils (currently = binutils-2.25) instead of /usr/bin/ tools it could then work in more = contexts. For all I know more than ld could also have vintage issues. I do not know if powerpc64 and powerpc have the only such = vintage-oddities around. Context details: # svnlite info /usr/ports/lang/clang36 Path: /usr/ports/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) # more /etc/make.conf=20 WRKDIRPREFIX=3D/usr/obj/portswork #WITH_DEBUG=3D MALLOC_PRODUCTION=3D =3D=3D=3D Mark Millard markmi at dsl-only.net