From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 15 00:38:55 2015 Return-Path: Delivered-To: freebsd-ppc@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 96FEBB8E 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 3FA8F7E1 for ; Sun, 15 Mar 2015 00:38:54 +0000 (UTC) Received: (qmail 11501 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 05:09:54 2015 Return-Path: Delivered-To: freebsd-ppc@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 A90908BC for ; Mon, 16 Mar 2015 05:09:54 +0000 (UTC) Received: from masa.qt7.net (masa.qt7.net [104.140.67.88]) by mx1.freebsd.org (Postfix) with ESMTP id 687D26F for ; Mon, 16 Mar 2015 05:09:54 +0000 (UTC) To: freebsd-ppc@freebsd.org Subject: wish to introduce our fleece blankets and bathrobes factory Message-ID: <8500be643bb3a5b3e05a313971caf567@canon.com> Date: Mon, 16 Mar 2015 06:06:16 +0100 From: "James" Reply-To: wanshancon@tom.com MIME-Version: 1.0 X-Mailer-LID: 26 X-Mailer-RecptId: 20219490 X-Mailer-SID: 118 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 05:09:54 -0000 We wish to introduce our fleece blankets and bathrobes factory Our factory based in China has been engaged in the manufacture and sales of fleece products for many years. Over the past years, we have got much professional experience in this industry. We produce below: polar fleece blankets micro coral fleece blankets picnic blankets cushions/cushion covers baby blankets embroidered blankets bathrobes voile curtains sauna quits fleece clothing washmachine covers Our products have been exported to North Amercia, Europe, Japan and so on. We are looking forward to start business with you soon. Best regards: James Contact: rightmm@tom.com From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 16 06:07:26 2015 Return-Path: Delivered-To: freebsd-ppc@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 E25B3E9B 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 98FEC806 for ; Mon, 16 Mar 2015 06:07:25 +0000 (UTC) Received: (qmail 14613 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 08:02:15 2015 Return-Path: Delivered-To: freebsd-ppc@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 D277EBB5 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 8241B36C for ; Mon, 16 Mar 2015 08:02:14 +0000 (UTC) Received: (qmail 4912 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: Baptiste Daroussin , freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 10:02:27 2015 Return-Path: Delivered-To: freebsd-ppc@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, Warner Losh , FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 11:51:56 2015 Return-Path: Delivered-To: freebsd-ppc@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 C5D84B84 for ; Mon, 16 Mar 2015 11:51:56 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) (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 8AC26174 for ; Mon, 16 Mar 2015 11:51:56 +0000 (UTC) Received: by padcy3 with SMTP id cy3so62897734pad.3 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=IOrc9NjghdYZpsLMeJlCzj/Lr+/LFKoci1l75gIiKHLr5NwwFr5M5MnToc3qgrsmDh BHT1ouaIzwV40AZ1NRr/w6hFjWCxEtfs0LMEHtSU3KBH5UmMkjDID5kLbpBcaOQ0IERL CDlzBNimybSwK40KPpGUNtt44HMDWQZPi9A4csjgZqd8odCA1yKgJapYg1vLPx7JGpaG 16LnqjgdbYffPuXeSF8wTr6W6WUh01as+BGIxNR4lsWCY2AqKg62D1XIm+hlCAIZ646x lHHIlrd+5WjbgX/Cv+WZf5cV5DMDMPibQnTdw1+pgpKzbF8alzggjzFUHpmaoqpBuWAE 7cFA== X-Gm-Message-State: ALoCoQkn3gj5HGWfwpa+Ien1CDx/K4V0z28yhJdG6m4ZKzYCwA3C4Q+nIB6T2U8FaJkjmH5YlkOF 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 11:51:56 -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-ppc@FreeBSD.ORG Mon Mar 16 13:26:11 2015 Return-Path: Delivered-To: freebsd-ppc@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 0771F5B4 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 A6CB7EA7 for ; Mon, 16 Mar 2015 13:26:09 +0000 (UTC) Received: (qmail 3409 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 14:03:53 2015 Return-Path: Delivered-To: freebsd-ppc@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 98441D01 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 549B5392 for ; Mon, 16 Mar 2015 14:03:52 +0000 (UTC) Received: (qmail 17753 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 14:41:46 2015 Return-Path: Delivered-To: freebsd-ppc@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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 15:12:58 2015 Return-Path: Delivered-To: freebsd-ppc@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 802BCCB 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 1ED60F6F for ; Mon, 16 Mar 2015 15:12:57 +0000 (UTC) Received: (qmail 32027 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 18:01:23 2015 Return-Path: Delivered-To: freebsd-ppc@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 70293F31 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 1FD41A85 for ; Mon, 16 Mar 2015 18:01:22 +0000 (UTC) Received: (qmail 23159 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Mon Mar 16 18:15:22 2015 Return-Path: Delivered-To: freebsd-ppc@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 E2BA3473 for ; Mon, 16 Mar 2015 18:15:22 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (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 55331C1F for ; Mon, 16 Mar 2015 18:15:22 +0000 (UTC) Received: by wixw10 with SMTP id w10so50758313wix.0 for ; Mon, 16 Mar 2015 11:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=+lNeyUHPKMLjt35dgFvCu2QceP2WlKVBGrl5LNiw1nA=; b=nuAkCPUhD+ZS0eUegZwkit88yi8DGbE5AA8VWch8uEbvNMcZdFbs56IODKFO883tKp chZiuqFjboKpO7a8PERcVfiUl2Pgt1TZ5GyQNgH14ovYqzTwoZ4c/4zSjg8AcTY75ugN ITwQjVe6xPedGiZsEKDRuxdrhs/TLRwmxwGql7rQF5ndXQl2w8b0PQXXQSzFAgyw0J2k DNP0BjnXU/c4QcjcrYGHKxacPQLMHRv9AVWqIsms/v0scmE5lvvd52smVxk9b7Jq7o+O 0gO/1PBsQZ2vJYIkxpqmo6qW+wf7JG5pzo7Rspqva8N4YTpuCJEgZo3Os6DNktxF+PFf pIYw== X-Received: by 10.194.108.137 with SMTP id hk9mr82915167wjb.112.1426529720701; Mon, 16 Mar 2015 11:15:20 -0700 (PDT) Received: from almani ([5.222.59.233]) by mx.google.com with ESMTPSA id ge8sm16447765wjc.32.2015.03.16.11.15.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 16 Mar 2015 11:15:18 -0700 (PDT) Message-ID: <017301da-42079-015a9064224653@almani> Reply-To: "Global Researchers Journals" From: "Global Researchers Journals" To: freebsd-ppc@freebsd.org Subject: Call for Paper {March 2015 | Vol 05-Issue 03} Date: Mon, 16 Mar 2015 21:45:18 +0330 X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 18:15:23 -0000 Call for Paper Dear Colleagues You are cordially invited to submit or recommend papers to: [1]http://www.grjournals.com (March 2015 (Volume 05 | Issue 03) Journal of Physiology and Pharmacology Advances (JPPA) [2]http://grjournals.com/Default.aspx?tabid=6537 · Journal of Animal Production Advances (JAPA) [3]http://grjournals.com/Default.aspx?tabid=6538 Journal of Animal Science Advances (JASA) [4]http://grjournals.com/Default.aspx?tabid=6401 Journal of Veterinary Advances (JVA) [5]http://grjournals.com/Default.aspx?tabid=6536 Journal of Recent Advances in Agriculture (JRAA) [6]http://grjournals.com/Default.aspx?tabid=6878 Global Researchers Journals, a fast track peer-reviewed and open access academic journal published by Grjournals Publishing, which is one of the largest open access journal publishers around the world Grjournals is using online article submission, review and tracking system for quality and quick review processing. Journal provides rapid publication of research article. After 30 days Rapid Review Process by the editorial/review board members or outside experts, an accepted paper will be placed under In Press within 24 hours and will be published in the next issue. Instructions for authors are available on our website: [7]http://www.grjournals.com Submitted papers must follow the Instructions to authors to be considered for review and publication. Refereeing of manuscripts is conducted anonymously and the identity of the referees is not disclosed. The manuscripts which get an acceptance will publish with DOI number. Your Manuscript(s) can be one of these kinds: Review, Original Article, Case Report, Short Communications, Technical Notes, Mini Review Article and Hypothesis. Some of Abstracted/Index in: CAB reviews, Chemical Abstract Service (CAS), Genamics JournalSeek, Index Directory of Open Access Journals (DOAJ), Index Electronic Journals Library SCIRUS, ISC and the World most Popular University and Electronic Library. [8]http://grjournals.com/Default.aspx?tabid=732 9 Now you can clear the clutter by accessing your favorite journals online: Full text, full archive that's always there when you need it Easy access anywhere, anytime and anyhow · Impact your practice, not the environment NOTICE: Authors that cite [9]www.grjournals.com manuscripts as reference in their ISI articles, they can send their manuscripts to one of above journals as FREE of charge. After evaluation and get an acceptance it will publish without any Article Processing Fee with DOI. .We apologize if you have received this email twice, or our journal is not your field With Warm Regards ,Sincerely Grjournals Team Site: [10]www.grjournals.com E_Mail: [11]grjournals@gmail.com References 1. http://www.grjournals.com/ 2. http://grjournals.com/Default.aspx?tabid=6537 3. http://grjournals.com/Default.aspx?tabid=6538 4. http://grjournals.com/Default.aspx?tabid=6401 5. http://grjournals.com/Default.aspx?tabid=6536 6. http://grjournals.com/Default.aspx?tabid=6878 7. http://www.grjournals.com/ 8. http://grjournals.com/Default.aspx?tabid=7329 9. http://www.grjournals.com/ 10. http://www.grjournals.com/ 11. mailto:grjournals@gmail.com From owner-freebsd-ppc@FreeBSD.ORG Tue Mar 17 00:04:43 2015 Return-Path: Delivered-To: freebsd-ppc@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 84269575 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 2D63AD07 for ; Tue, 17 Mar 2015 00:04:42 +0000 (UTC) Received: (qmail 26088 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 00:18:44 2015 Return-Path: Delivered-To: freebsd-ppc@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 68AB4972 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 0C857E09 for ; Tue, 17 Mar 2015 00:18:43 +0000 (UTC) Received: (qmail 27745 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 01:23:39 2015 Return-Path: Delivered-To: freebsd-ppc@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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 03:00:59 2015 Return-Path: Delivered-To: freebsd-ppc@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 29C7AF78 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 D4BE4F8A for ; Tue, 17 Mar 2015 03:00:58 +0000 (UTC) Received: (qmail 23012 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 03:37:54 2015 Return-Path: Delivered-To: freebsd-ppc@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 813B3E4C 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 38695643 for ; Tue, 17 Mar 2015 03:37:53 +0000 (UTC) Received: (qmail 11054 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 05:36:54 2015 Return-Path: Delivered-To: freebsd-ppc@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 93FF4A24 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 45AA2104 for ; Tue, 17 Mar 2015 05:36:53 +0000 (UTC) Received: (qmail 9459 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 06:00:54 2015 Return-Path: Delivered-To: freebsd-ppc@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 2D969B7 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 D85D52FF for ; Tue, 17 Mar 2015 06:00:53 +0000 (UTC) Received: (qmail 25105 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 09:19:53 2015 Return-Path: Delivered-To: freebsd-ppc@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 2C391AE4 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 D8011CCC for ; Tue, 17 Mar 2015 09:19:51 +0000 (UTC) Received: (qmail 3202 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 09:26:36 2015 Return-Path: Delivered-To: freebsd-ppc@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 D15E3D9F 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 80C06DC1 for ; Tue, 17 Mar 2015 09:26:36 +0000 (UTC) Received: (qmail 12077 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 12:59:48 2015 Return-Path: Delivered-To: freebsd-ppc@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 6C9DA5AE for ; Tue, 17 Mar 2015 12:59:48 +0000 (UTC) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (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 F34C2AA1 for ; Tue, 17 Mar 2015 12:59:47 +0000 (UTC) Received: by wegp1 with SMTP id p1so7032130weg.1 for ; Tue, 17 Mar 2015 05:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=v9dpcMo8/EJC1mHnooyowEtGHPd5qVEgquvVqZZ71PE=; b=vIx0dEVtxYUvCHYmxh4zjB1CfgoEeEke5SCtdTzuqJ1V2xHJ1BKbyy/BafzueV9F45 k17MXeORV/C6OTqUaID8na4u0ZtIG2wK5kXc1NtoBa+67zunPTsKOYvMB67i5Y6P93xF 3tsK4ndw0UiTL8Ss3BWnXsMCpNit8bMOUMoPYE+I1RnPlkXi5o6Fz8xRYIRdepTvBW7S 9cmkrsAINtyceHZ+sGjufTLNQ46rhEhy759VlEXk7qAfQ0fr/TnyfofW0z+4frf17h7+ K0vYVZVert2j3TF6d/0tSikcI7F4cY1EzJ1tcVUzggZjSNPj5W0udmI9mA7AvgquYStB a26A== X-Received: by 10.180.76.147 with SMTP id k19mr98871558wiw.92.1426597186354; Tue, 17 Mar 2015 05:59:46 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by mx.google.com with ESMTPSA id s19sm2558273wik.18.2015.03.17.05.59.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 05:59:45 -0700 (PDT) Message-ID: <55082540.1020001@gmail.com> Date: Tue, 17 Mar 2015 14:59:44 +0200 From: Jukka Ukkonen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-ppc@FreeBSD.org Subject: Something missing perhaps? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:59:48 -0000 Hello all, I was trying to build kyotocabinet from the ports tree on an old PowerMac G4 Quicksilver, but the attempt failed in a very peculiar manner... Do these complaints from cc ring any bells... ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' ./libkyotocabinet.so: undefined reference to `__sync_bool_compare_and_swap_8' ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' ./libkyotocabinet.so: undefined reference to `__sync_bool_compare_and_swap_8' Those missing names are apparenly being referenced by work/kyotocabinet-1.2.76/kcthread.cc. Since I failed to find the definition of these names anywhere in the kyotocabinet source, I assume the names are used in some compiler header file. Were those names really intended to be in the headers as-is or were they actually some sort of place holders for something which have then been completely forgotten for some reason? The all important details of the system are... # uname -a FreeBSD yggdrasil 10.1-STABLE FreeBSD 10.1-STABLE #0 r280132: Mon Mar 16 06:12:57 EET 2015 root@yggdrasil:/opt2/obj/usr/src-10.1/sys/GENERIC powerpc # uname -KU 1001510 1001510 # freebsd-version -ku 10.1-STABLE 10.1-STABLE --jau From owner-freebsd-ppc@FreeBSD.ORG Tue Mar 17 17:57:07 2015 Return-Path: Delivered-To: freebsd-ppc@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 15133AD9 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 BB4B0B4 for ; Tue, 17 Mar 2015 17:57:06 +0000 (UTC) Received: (qmail 4453 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 18:35:34 2015 Return-Path: Delivered-To: freebsd-ppc@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 35FEB4DE for ; Tue, 17 Mar 2015 18:35:34 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 A3D656E6 for ; Tue, 17 Mar 2015 18:35:33 +0000 (UTC) Received: by labjg1 with SMTP id jg1so16462422lab.2 for ; Tue, 17 Mar 2015 11:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Of1P59rKdv4aSS/Bn35Sm3vCcGepUUzLLTFYhF+qEos=; b=W3U0SahYiwh0L670zkCmT5ITxQrFUAK5WPbtO+gUSrw12qrtoW40Nt6pgyzTX/pIrq q0x4qrlFhR/GGMquxM+FjE8STtoYvbH/C29QpI5FsNG3VGNylG6wQ7jIDXlXibD8Pqn6 ZJENf+DZTbdbDUJfd3nCzy2JxGcLvKJpPg38GKxj2IQgOQXeUoBCDmfoNuf1GYcIGgXW 7H81Re1L7oOjRYVr2YkrI4LdyjKzjlTuSyx3CWesJ/+AYcYsB6ZNgYmlNdBCPKUXCXq3 eZMyT0xkzF7RW4qwIlQaJC08GYrcigED5WOoyvBGqZ7uM26ke4yXlk1tix0pnpWM77wE 57Zg== MIME-Version: 1.0 X-Received: by 10.112.62.135 with SMTP id y7mr60720024lbr.50.1426617331666; Tue, 17 Mar 2015 11:35:31 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.25.145.65 with HTTP; Tue, 17 Mar 2015 11:35:31 -0700 (PDT) In-Reply-To: <55082540.1020001@gmail.com> References: <55082540.1020001@gmail.com> Date: Tue, 17 Mar 2015 11:35:31 -0700 X-Google-Sender-Auth: RNojc3w2_g9Kka3DKyiJF-ByAcI Message-ID: Subject: Re: Something missing perhaps? From: Justin Hibbits To: Jukka Ukkonen Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:35:34 -0000 These symbol references are generated by the compiler to handle 64-bit atomic operations. I don't think there's currently any support, even in libgcc, for 64-bit atomics on 32-bit powerpc. Something *could* be hacked together to handle it, using a mutex wrapper, but to the best of my knowledge, nobody's done the work for it. - Justin On Tue, Mar 17, 2015 at 5:59 AM, Jukka Ukkonen wrote: > > Hello all, > > I was trying to build kyotocabinet from the ports tree > on an old PowerMac G4 Quicksilver, but the attempt failed > in a very peculiar manner... > Do these complaints from cc ring any bells... > > ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' > ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' > ./libkyotocabinet.so: undefined reference to > `__sync_bool_compare_and_swap_8' > ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' > ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' > ./libkyotocabinet.so: undefined reference to > `__sync_bool_compare_and_swap_8' > > Those missing names are apparenly being referenced by > work/kyotocabinet-1.2.76/kcthread.cc. Since I failed > to find the definition of these names anywhere in the > kyotocabinet source, I assume the names are used in > some compiler header file. > Were those names really intended to be in the headers > as-is or were they actually some sort of place holders > for something which have then been completely forgotten > for some reason? > > The all important details of the system are... > > # uname -a > FreeBSD yggdrasil 10.1-STABLE FreeBSD 10.1-STABLE #0 r280132: Mon Mar 16 > 06:12:57 EET 2015 root@yggdrasil:/opt2/obj/usr/src-10.1/sys/GENERIC > powerpc > > # uname -KU > 1001510 1001510 > > # freebsd-version -ku > 10.1-STABLE > 10.1-STABLE > > > --jau > _______________________________________________ > 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" From owner-freebsd-ppc@FreeBSD.ORG Tue Mar 17 19:12:10 2015 Return-Path: Delivered-To: freebsd-ppc@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 8ADBC46B for ; Tue, 17 Mar 2015 19:12:10 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 7071EBEB for ; Tue, 17 Mar 2015 19:12:10 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2HJCA32054911 for ; Tue, 17 Mar 2015 19:12:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 135576] gdb cannot debug threaded programs on ppc Date: Tue, 17 Mar 2015 19:12:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: powerpc X-Bugzilla-Version: 1.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jhibbits@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-ppc@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:12:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=135576 Justin Hibbits changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |Overcome By Events CC| |jhibbits@FreeBSD.org --- Comment #1 from Justin Hibbits --- devel/gdb can debug threaded programs on powerpc. Base gdb can debug threaded programs on powerpc64. Since base gdb will likely be removed in the not too distant future, closing this. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-ppc@FreeBSD.ORG Tue Mar 17 20:24:46 2015 Return-Path: Delivered-To: freebsd-ppc@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 973A3647 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 4853E6C3 for ; Tue, 17 Mar 2015 20:24:45 +0000 (UTC) Received: (qmail 31903 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Tue Mar 17 21:16:42 2015 Return-Path: Delivered-To: freebsd-ppc@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 4DFEE8E0 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 F3BD6D2E for ; Tue, 17 Mar 2015 21:16:41 +0000 (UTC) Received: (qmail 22076 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Wed Mar 18 03:02:52 2015 Return-Path: Delivered-To: freebsd-ppc@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 7106DAEA 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 29039BD5 for ; Wed, 18 Mar 2015 03:02:51 +0000 (UTC) Received: (qmail 5010 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Wed Mar 18 06:38:49 2015 Return-Path: Delivered-To: freebsd-ppc@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 F31D9FD4 for ; Wed, 18 Mar 2015 06:38:48 +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 61E02196 for ; Wed, 18 Mar 2015 06:38:48 +0000 (UTC) Received: by lbbsy1 with SMTP id sy1so22793342lbb.1 for ; Tue, 17 Mar 2015 23:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=4jKplhUHBOSDesAs6uFnv4afYV9g49ptBYyR6km+nIs=; b=lkgmpLMFZm/TL4wQZLQ5hOJXtJGkYnkWPoCyc4ylR1NO97HagBm79ee0N7exlrv2Hv 8ItJkklSw+CPMr7Z1B7NqfB3RRX45K0CAlqj/5wMJNPtUbhKNg3V4D5ahJrmTHP9qeuJ tCQpuEE8rws1n7An1Yq4GD7dTc79LOiQ1K0y0XgQFP3y81/+OekQRc9FVxusJIAVOU4C 9WrUfNPCTXHRg7GQcoJbM1Nd8p0YaSEmeO5yOq6ygnMV4LskZOIj+i5YbfDUtQllm0aP HsaA8MqdfMA+pP3LBKq6kXn4kN43jEhj5h4S/y06Qct90ie0Uo/JoL98txEnibIYot8K 5UXA== X-Received: by 10.152.19.9 with SMTP id a9mr63844463lae.80.1426660725981; Tue, 17 Mar 2015 23:38:45 -0700 (PDT) Received: from [192.168.1.130] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by mx.google.com with ESMTPSA id d6sm3197241lbp.16.2015.03.17.23.38.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 23:38:45 -0700 (PDT) Message-ID: <55091DB7.7010601@gmail.com> Date: Wed, 18 Mar 2015 08:39:51 +0200 From: Jukka Ukkonen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Hibbits Subject: Re: Something missing perhaps? References: <55082540.1020001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 06:38:49 -0000 Right, it did not occur to me to blame it on the compiler, but that certainly is an excellent explanation. If I understood correctly sync_lock_test_and_set_8 should then be an alias to***atomic_testandset_64* , sync_fetch_and_add_8 an alias to *atomic_fetchadd_* *64*, and sync_bool_compare_and_swap an alias to* atomic_cmpset_acq_64*. Then the problem is shifted to the 64 bit atomic operations not having been implemented at all for 32 bit ppc. This is clearly due to the fact that the ldarx instruction etc, which would be the native HW method for implementing the 64 bit atomic operations, are only available on ppc64, not on ppc32. Ref. sys/powerpc/include/atomic.h and http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/ldarx.htm This being the case it kind of makes sense to ask why should the compiler try to use 64 bit atomic operations in the first place on a system which does not support them natively? In my mind it would be immensely better (read more efficient) to drop the ball back to the programmers forcing them to use data types suitable for the hardware. --jau On 2015-03-17 20:35, Justin Hibbits wrote: > These symbol references are generated by the compiler to handle 64-bit > atomic operations. I don't think there's currently any support, even > in libgcc, for 64-bit atomics on 32-bit powerpc. Something *could* be > hacked together to handle it, using a mutex wrapper, but to the best > of my knowledge, nobody's done the work for it. > > - Justin > > On Tue, Mar 17, 2015 at 5:59 AM, Jukka Ukkonen wrote: >> Hello all, >> >> I was trying to build kyotocabinet from the ports tree >> on an old PowerMac G4 Quicksilver, but the attempt failed >> in a very peculiar manner... >> Do these complaints from cc ring any bells... >> >> ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' >> ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' >> ./libkyotocabinet.so: undefined reference to >> `__sync_bool_compare_and_swap_8' >> ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' >> ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' >> ./libkyotocabinet.so: undefined reference to >> `__sync_bool_compare_and_swap_8' >> >> Those missing names are apparenly being referenced by >> work/kyotocabinet-1.2.76/kcthread.cc. Since I failed >> to find the definition of these names anywhere in the >> kyotocabinet source, I assume the names are used in >> some compiler header file. >> Were those names really intended to be in the headers >> as-is or were they actually some sort of place holders >> for something which have then been completely forgotten >> for some reason? >> >> The all important details of the system are... >> >> # uname -a >> FreeBSD yggdrasil 10.1-STABLE FreeBSD 10.1-STABLE #0 r280132: Mon Mar 16 >> 06:12:57 EET 2015 root@yggdrasil:/opt2/obj/usr/src-10.1/sys/GENERIC >> powerpc >> >> # uname -KU >> 1001510 1001510 >> >> # freebsd-version -ku >> 10.1-STABLE >> 10.1-STABLE >> >> >> --jau >> _______________________________________________ >> 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" From owner-freebsd-ppc@FreeBSD.ORG Wed Mar 18 06:49:08 2015 Return-Path: Delivered-To: freebsd-ppc@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 6DC63197 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 033E0275 for ; Wed, 18 Mar 2015 06:49:07 +0000 (UTC) Received: (qmail 11656 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Wed Mar 18 07:12:36 2015 Return-Path: Delivered-To: freebsd-ppc@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 128BB713; Wed, 18 Mar 2015 07:12:36 +0000 (UTC) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (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 A1F98773; Wed, 18 Mar 2015 07:12:35 +0000 (UTC) Received: by ladw1 with SMTP id w1so28375244lad.0; Wed, 18 Mar 2015 00:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZkinbVmyx2QUSq6LZJKYEaix8iZQAoGdXINjUCWNz5I=; b=wEMln9L6sqIRxgZ7SpDdSrDEND8cYOzTkwAelUCz88FiNaQq6EbT5Jud3K3LZRLjpY 6fk1XjYz9zDN+DgzlbrlzWMuGXVmU+g0AhAtlMpy/H4tW5rOL4y64uzjAcNZGNYt/vlk VNEmoTKaEmgMatk9EikHnL+n09Nm7i4igocpgPNl8FqcLeKlYH2poINOE4pYGfiYl8Yv W8iKpSDfu39WcIEP4oCpyQl7atnfNWJNfeqpEkFqP29zAnXKIyFNAWxKofpy5wStAtpN 1lrHhTa/ajvzvzhf7PUpBCkbB9dpsHr92WLkLF24ir4OOjdCpe9K73RvL8xu4Et8OwxA 5xjQ== X-Received: by 10.152.19.9 with SMTP id a9mr63943659lae.80.1426662753587; Wed, 18 Mar 2015 00:12:33 -0700 (PDT) Received: from [192.168.1.31] (gero.in. [77.37.212.15]) by mx.google.com with ESMTPSA id dq7sm3203734lac.25.2015.03.18.00.12.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 00:12:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Request for testing an alternate branch From: lausgans@gmail.com In-Reply-To: Date: Wed, 18 Mar 2015 10:12:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Justin Hibbits , hrs@FreeBSD.org X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD Current , FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 07:12:36 -0000 > 6 =D0=B4=D0=B5=D0=BA. 2013 =D0=B3., =D0=B2 23:40, Justin Hibbits = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0):= >=20 > On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits = wrote: >> I've been working on the projects/pmac_pmu branch for some time now = to >> add suspend/resume as well as CPU speed change for certain PowerPC >> machines, about a year since I created the branch, and now it's = stable >> enough that I want to merge it into HEAD, hence this request. Thanks for your work! What is the estimated time when it will go HEAD? May I expect that my powerbook4,1 machine will get ability to sleep = under the FreeBSD now? >> However, >> it does touch several drivers, turning them into "early drivers", = such >> that they can be initialized, and suspended and resumed at a = different >> time. Saying that, I do need testing from other architectures, to = make >> sure I haven't broken anything. >>=20 >> The technical details: >>=20 >> To get proper ordering, I've extended the bus_generic_suspend() and >> bus_generic_resume() to do multiple passes. Devices which cannot be >> enabled or disabled at the current pass level would return an EAGAIN. >> This could possibly cause problems, since it's an addition to an >> existing API rather than a new API to run along side it, so it needs = a >> great deal of testing. It works fine on PowerPC, but I don't have = any >> i386/amd64 or sparc64 hardware to test it on, so would like others = who >> do to test it. I don't thin >>=20 >> Also, any comments are of course welcome. Technical concerns are >> obviously welcome, and I will try to address everything. >>=20 >> Thanks, >>=20 >> Justin >=20 > Thanks to hrs@, images are now available for the pmac_pmu project on > allbsd for i386, amd64, sparc64, and ia64: > https://pub.allbsd.org/FreeBSD-snapshots/ . I understand that you provided these so people with another archs could = test whether it doesn't break anything, but what about actual PPC users? = ;) Considering that powerpc is a Tier 2 these days, it's not that easy even = to get svn quickly for it to grab your tree, so I would ask adding = projects_pmac_pmu to the powerpc building. Thanks. >=20 > - Justin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current >=20 From owner-freebsd-ppc@FreeBSD.ORG Wed Mar 18 14:32:27 2015 Return-Path: Delivered-To: freebsd-ppc@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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Wed Mar 18 16:41:55 2015 Return-Path: Delivered-To: freebsd-ppc@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 B4E3AA17; Wed, 18 Mar 2015 16:41:55 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 4F78766E; Wed, 18 Mar 2015 16:41:55 +0000 (UTC) Received: by lbblx11 with SMTP id lx11so11832964lbb.3; Wed, 18 Mar 2015 09:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=VtIGoK++tXVqUzw3ml/pLfGbCGgHEb7zm5RGhCReSHY=; b=fb2V+PId9lfrzMeqoZqor9aldrzPtgh7f/PSozdu4EVwbdzb7If0/tgZ3/EvV9+2ID jpUq5Qqtd+Wt0FS87+5qcN6jOwgLf2V/nM+8VrG3G6NG8jvpdTy1KCTlIa7f1Q7eHnnM V/PATO6hNp+pZQ4NnwjSy1I4L72HKkX6TtscgdSlAObRez7VhaKw+Kfhw9Oj7nBw4K03 KxfjgkHft5pm9ZPf6bfcvqt6pnvYTGBVM5WtWjqQcLatggZZbzTm19T5R0UrX3UyG5UD VorrX8KZzs+JmyazeC/y7xWpm184bsv6hHHk/+ZfoDcxtMy8VjrDRCfTxewFPtYJPuLf XCcA== MIME-Version: 1.0 X-Received: by 10.112.25.38 with SMTP id z6mr14606916lbf.106.1426696912983; Wed, 18 Mar 2015 09:41:52 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.25.145.65 with HTTP; Wed, 18 Mar 2015 09:41:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Mar 2015 09:41:52 -0700 X-Google-Sender-Auth: NQyTjgIPYrY4ilrnHuU_8jfiNrU Message-ID: Subject: Re: Request for testing an alternate branch From: Justin Hibbits To: lausgans@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD PowerPC ML , FreeBSD Current X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:41:55 -0000 On Wed, Mar 18, 2015 at 12:12 AM, wrote: > >> 6 =D0=B4=D0=B5=D0=BA. 2013 =D0=B3., =D0=B2 23:40, Justin Hibbits =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >> >> On Wed, Dec 4, 2013 at 10:19 PM, Justin Hibbits w= rote: >>> I've been working on the projects/pmac_pmu branch for some time now to >>> add suspend/resume as well as CPU speed change for certain PowerPC >>> machines, about a year since I created the branch, and now it's stable >>> enough that I want to merge it into HEAD, hence this request. > > Thanks for your work! What is the estimated time when it will go HEAD? > May I expect that my powerbook4,1 machine will get ability to sleep under= the FreeBSD now? > >>> However, >>> it does touch several drivers, turning them into "early drivers", such >>> that they can be initialized, and suspended and resumed at a different >>> time. Saying that, I do need testing from other architectures, to make >>> sure I haven't broken anything. >>> >>> The technical details: >>> >>> To get proper ordering, I've extended the bus_generic_suspend() and >>> bus_generic_resume() to do multiple passes. Devices which cannot be >>> enabled or disabled at the current pass level would return an EAGAIN. >>> This could possibly cause problems, since it's an addition to an >>> existing API rather than a new API to run along side it, so it needs a >>> great deal of testing. It works fine on PowerPC, but I don't have any >>> i386/amd64 or sparc64 hardware to test it on, so would like others who >>> do to test it. I don't thin >>> >>> Also, any comments are of course welcome. Technical concerns are >>> obviously welcome, and I will try to address everything. >>> >>> Thanks, >>> >>> Justin >> >> Thanks to hrs@, images are now available for the pmac_pmu project on >> allbsd for i386, amd64, sparc64, and ia64: >> https://pub.allbsd.org/FreeBSD-snapshots/ . > > I understand that you provided these so people with another archs could t= est whether it doesn't break anything, but what about actual PPC users? ;) > Considering that powerpc is a Tier 2 these days, it's not that easy even = to get svn quickly for it to grab your tree, so I would ask adding projects= _pmac_pmu to the powerpc building. Thanks. There were some design decisions that people took issue with, so I've been working on that. I plan to merge the bulk of the work into HEAD soon, but only the driver suspend/resume routines. The additional updates for suspending the system as a whole won't be made for some time, due to the intrusiveness of the change. I'm still planning for this to be completed for the 11.0 release, and with the bulk of the work completed, that should be feasible. I don't have a PowerBook4,1 to test with, but I think it should work, but some drivers may not resume properly. - Justin From owner-freebsd-ppc@FreeBSD.ORG Wed Mar 18 21:39:09 2015 Return-Path: Delivered-To: freebsd-ppc@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 2B625F3D 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 D7A58EB3 for ; Wed, 18 Mar 2015 21:39:07 +0000 (UTC) Received: (qmail 31812 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Thu Mar 19 02:40:39 2015 Return-Path: Delivered-To: freebsd-ppc@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 67011C65 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 1F1C4349 for ; Thu, 19 Mar 2015 02:40:38 +0000 (UTC) Received: (qmail 11341 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Thu Mar 19 04:29:03 2015 Return-Path: Delivered-To: freebsd-ppc@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 66A2CB45 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 1DDACFDE for ; Thu, 19 Mar 2015 04:29:02 +0000 (UTC) Received: (qmail 4176 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Thu Mar 19 09:26:40 2015 Return-Path: Delivered-To: freebsd-ppc@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 3B485A2 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 E57CF19D for ; Thu, 19 Mar 2015 09:26:39 +0000 (UTC) Received: (qmail 4041 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Thu Mar 19 12:13:06 2015 Return-Path: Delivered-To: freebsd-ppc@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 388C7BDF 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 B2FEB87F for ; Thu, 19 Mar 2015 12:13:05 +0000 (UTC) Received: (qmail 8793 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Fri Mar 20 05:00:49 2015 Return-Path: Delivered-To: freebsd-ppc@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 67680CBC for ; Fri, 20 Mar 2015 05:00:49 +0000 (UTC) Received: from shanghai.880288.net (shanghai.880288.net [5.255.87.147]) by mx1.freebsd.org (Postfix) with ESMTP id B9CE0F29 for ; Fri, 20 Mar 2015 05:00:48 +0000 (UTC) To: freebsd-ppc@freebsd.org Subject: need photo clipping path and retouching? Message-ID: <89bf8166eb63cab26b4c43e46366909f@brumbyrocker.com> Date: Fri, 20 Mar 2015 05:55:17 +0100 From: "David" Reply-To: yanggepai@sina.com MIME-Version: 1.0 X-Mailer-LID: 9 X-Mailer-RecptId: 8812763 X-Mailer-SID: 228 X-Mailer-Sent-By: 1 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 05:00:49 -0000 Hope this email finds you well! We are willing to introduce our photo retouching services today. We mainly specialize in below services: photoshop photos editing/retouching jewellery photos editing ecommerce products photo editing photo cutting out/clipping path beauty/skin retouching, wedding photos editing, and photo background manipulation. You may choose to send us a photo for free testing to check our quality Looking forward to receive your soonest response. Best regards, David Email: editexpert@tom.com From owner-freebsd-ppc@FreeBSD.ORG Fri Mar 20 21:17:37 2015 Return-Path: Delivered-To: freebsd-ppc@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 063D4BC 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 B4155D27 for ; Fri, 20 Mar 2015 21:17:35 +0000 (UTC) Received: (qmail 13370 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Sat Mar 21 01:04:57 2015 Return-Path: Delivered-To: freebsd-ppc@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 ACAE285D 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 65CC591E for ; Sat, 21 Mar 2015 01:04:56 +0000 (UTC) Received: (qmail 780 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Sat Mar 21 06:27:24 2015 Return-Path: Delivered-To: freebsd-ppc@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 50A3CCD3 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 05A66BF5 for ; Sat, 21 Mar 2015 06:27:23 +0000 (UTC) Received: (qmail 25139 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@FreeBSD.ORG Sat Mar 21 23:26:08 2015 Return-Path: Delivered-To: freebsd-ppc@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 161F1A5 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 C0277A14 for ; Sat, 21 Mar 2015 23:26:06 +0000 (UTC) Received: (qmail 625 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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