From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 9 03:23:37 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24199708 for ; Mon, 9 Mar 2015 03:23: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 D258819B for ; Mon, 9 Mar 2015 03:23:36 +0000 (UTC) Received: (qmail 28406 invoked from network); 9 Mar 2015 03:23:35 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Mar 2015 03:23:35 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 23:23:35 -0400 (EDT) Received: (qmail 10037 invoked from network); 9 Mar 2015 03:23:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Mar 2015 03:23: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 4FD6A1C43A2; Sun, 8 Mar 2015 20:23:28 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc (non-64) 10.1-STABLE context: CXXLD mesa_dri_drivers.la gets c++: Internal error: Segmentation fault (program ld) Message-Id: <55D5E445-4018-488D-B776-9CA5A062A904@dsl-only.net> Date: Sun, 8 Mar 2015 20:23:32 -0700 To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 03:23:37 -0000 Basic context information (more details later): # freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG4S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Sun Mar 8 = 14:09:34 PDT 2015 = root@FBSDG4S0:/usr/obj/powerpc.powerpc/usr/src/sys/GENERICvtsc powerpc This variant of powerpc GENERIC (not GENERIC64) was running on a = PowerMac G5 Quad-Core, not that I expect that matters for the below. The problem: For the above powerpc port-build context graphics/dri failed to build = because of a segmentation fault during a CXXLD mesa_dri_drivers.la . ... =3D=3D=3D>>> Launching child to install graphics/dri =3D=3D=3D>>> x11/xorg 13/16 >> graphics/dri (1/212) portmaster: x11/xorg 13/16 >> graphics/dri (1/212) =3D=3D=3D>>> Port directory: /usr/ports/graphics/dri =3D=3D=3D>>> Starting check for all dependencies =3D=3D=3D>>> Gathering dependency list for graphics/dri from ports =3D=3D=3D>>> Dependency check complete for graphics/dri =3D=3D=3D>>> x11/xorg 13/16 >> graphics/dri (1/212) portmaster: x11/xorg 13/16 >> graphics/dri (1/12) =3D=3D=3D> Cleaning for dri-10.4.5,2 ... CC swrast.lo CCLD libswrast_dri.la gmake[7]: Leaving directory = '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.4.5/src/mesa/drive= rs/dri/swrast' gmake[7]: Entering directory = '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.4.5/src/mesa/drive= rs/dri' cd ../../../.. && gmake am--refresh cd ../../../.. && gmake am--refresh CXXLD mesa_dri_drivers.la c++: Internal error: Segmentation fault (program ld) Please submit a full bug report. See for instructions. Makefile:651: recipe for target 'mesa_dri_drivers.la' failed gmake[7]: *** [mesa_dri_drivers.la] Error 1 gmake[7]: Leaving directory = '/usr/obj/portswork/usr/ports/graphics/dri/work/Mesa-10.4.5/src/mesa/drive= rs/dri' Makefile:737: recipe for target 'all-recursive' failed gmake[6]: *** [all-recursive] Error 1 ... Other context details: $ 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) $ 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 sys/powerpc/ofw/ofw_machdep.c has a powerpc64 PowerMac G5 specific = change to avoid intermittent boot problems. For powerpc the #if = structure avoids the change. 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. But here = ofwcall64.S was not in use and I've not yet put such an addition into = ofwcall.S . DDB and GDB are listed in sys/powerpc/conf/GENERICvtsc for = the same reason. 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. sys/powerpc/conf/GENERICvtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC. # more /etc/make.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D MALLOC_PRODUCTION=3D # more /etc/src.conf #CPP=3Dclang-cpp #CC=3Dclang #CXX=3Dclang++ #CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG # 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. # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc-unknown-freebsd10.1 Thread model: posix There is no port-based gcc/g++ or clang present. $ 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) $ svnlite st --no-ignore ? .snap I distfiles M graphics/libGL/bsd.mesalib.mk I packages ? restoresymtable $ 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 +.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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Mon Mar 9 15:09:17 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB29B296 for ; Mon, 9 Mar 2015 15:09:17 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 6F9F16D3 for ; Mon, 9 Mar 2015 15:09:16 +0000 (UTC) Received: (qmail 5567 invoked from network); 9 Mar 2015 15:09:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 9 Mar 2015 15:09:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 09 Mar 2015 11:09:10 -0400 (EDT) Received: (qmail 9129 invoked from network); 9 Mar 2015 15:09:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Mar 2015 15:09:09 -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 3C613B1E002; Mon, 9 Mar 2015 08:09:06 -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: Date: Mon, 9 Mar 2015 08:09:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> References: <54FC7D92.3010405@freebsd.org> To: Nathan Whitehorn , freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 15:09:17 -0000 I've discovered why/how WITH_DEBUG=3D ends up with cmake's = /usr/local/bin/ctest messed up for PIC code generation (powerpc64 = context). A source code fix that avoids the problem is likely to change = cmake's hashtable.hxx that has inline size_t _stl_next_prime(size_t __n) { const unsigned long* __first =3D get_stl_prime_list(); const unsigned long* __last =3D get_stl_prime_list() + = (int)_stl_num_primes; const unsigned long* pos =3D cmsys_stl::lower_bound(__first, __last, = __n); return pos =3D=3D __last ? *(__last - 1) : *pos; } to also indicate static for it like the .hxx file has for static inline const unsigned long* get_stl_prime_list() { static const unsigned long _stl_prime_list[_stl_num_primes] =3D { 5ul, 11ul, 23ul, 53ul, 97ul, 193ul, 389ul, 769ul, 1543ul, 3079ul, 6151ul, 12289ul, 24593ul, 49157ul, 98317ul, 196613ul, 393241ul, 786433ul, 1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul, 50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul, 1610612741ul, 3221225473ul, 4294967291ul }; return &_stl_prime_list[0]; } NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that = exist in the source code. The details for what is going on follow... There are 7 instances of get_stl_prime_list's code in my = /usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 = values to allow finding appropriate _stl_prime_list addresses in various = places that include the header file. Each code instance from my build's = /usr/local/bin/ctest is shown below. (Note that the = ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the = distinct addresses.) But there is only 1 instance of _stl_next_prime's code in = /usr/local/bin/ctest, also shown below. This routine directly calls the = first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, = effectively forcing the %r2 offset from that code to always be used = --and so generating garbage addresses for 6 of the 7 static contexts. 6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused. But most of the initial usage of _stl_next_prime in execution order = happens to have the %r2 value that goes with the first = ._ZN5cmsysL18get_stl_prime_listEv routine. That is why = /usr/local/bin/ctest dies as late as it does. I have observed the indicated behavior leading up to the crash under gdb = as well. 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2976(r2) 00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2720(r2) 000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,2088(r2) 00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,11344(r2) 000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-32728(r2) 00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-26608(r2) 000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-21280(r2) 00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) And here is the only _stl_next_prime routine: 0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr r0 0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std r31,-8(r1) 000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std r0,16(r1) 0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu r1,-176(r1) 0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr r31,r1 0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std = r3,224(r31) 000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr r0,r3 0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std = r0,128(r31) 0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr r9,r3 00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi r0,r9,248 00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std = r0,120(r31) 00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld = r3,128(r31) 00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld = r4,120(r31) 00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi r0,r31,224 00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr r5,r0 00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl = 0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_> 00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove = 4*cr7+so,4*cr7+so 00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr r0,r3 00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std = r0,112(r31) 00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld = r9,112(r31) 00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld = r0,120(r31) 00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd cr7,r9,r0 00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne- = cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> 00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld = r9,120(r31) 00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi r9,r9,-8 00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld r9,0(r9) 00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std = r9,144(r31) 00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b = 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> 00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld = r9,112(r31) 00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9) 00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std = r9,144(r31) 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld = r0,144(r31) 00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr r3,r0 0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld r1,0(r1) 0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld r0,16(r1) 0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr r0 000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld r31,-8(r1) 0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr 0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0 0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001 000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz r0,1(r1) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 06:35 PM, Mark Millard wrote: Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) = --cyan "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 10 20:12:03 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C3AE63C for ; Tue, 10 Mar 2015 20:12:03 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (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 30B888EA for ; Tue, 10 Mar 2015 20:12:02 +0000 (UTC) Received: (qmail 3008 invoked from network); 10 Mar 2015 20:11:54 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Mar 2015 20:11:54 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 10 Mar 2015 16:11:54 -0400 (EDT) Received: (qmail 31390 invoked from network); 10 Mar 2015 20:11:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Mar 2015 20:11:54 -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 789801C43AC; Tue, 10 Mar 2015 13:11:49 -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: <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> Date: Tue, 10 Mar 2015 13:11:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21202F99-B759-4888-8C7E-5F65D4346F96@dsl-only.net> References: <54FC7D92.3010405@freebsd.org> <021318C0-0D3C-4950-AFB5-9B15E3BD3376@dsl-only.net> To: Nathan Whitehorn , freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 20:12:03 -0000 Brad King is adding the missing static to _stl_next_prime in KWSys and = from there it will eventually propagate into CMake's code base. Actually = in KWSys both static's are to be added. ( = http://review.source.kitware.com/#/c/19465/ ) Brad wrote that CMake's code base had added the static to = _get_stl_prime_list to handle a linking problem in some environment. = (Despite not knowing of KWSys I had guessed that there was some reason = why that static was there: that is why I suggested the direction of = making _stl_next_prime match instead of suggesting removing the static = on _get_stl_prime_list.) Once propagated the updates will make KWSys and = CMake's code again match in this area. So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG=3D= to be better behaved for CMake's programs that use it's hashtable.hxx . =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-9, at 08:09 AM, Mark Millard wrote: I've discovered why/how WITH_DEBUG=3D ends up with cmake's = /usr/local/bin/ctest messed up for PIC code generation (powerpc64 = context). A source code fix that avoids the problem is likely to change = cmake's hashtable.hxx that has inline size_t _stl_next_prime(size_t __n) { const unsigned long* __first =3D get_stl_prime_list(); const unsigned long* __last =3D get_stl_prime_list() + = (int)_stl_num_primes; const unsigned long* pos =3D cmsys_stl::lower_bound(__first, __last, = __n); return pos =3D=3D __last ? *(__last - 1) : *pos; } to also indicate static for it like the .hxx file has for static inline const unsigned long* get_stl_prime_list() { static const unsigned long _stl_prime_list[_stl_num_primes] =3D { 5ul, 11ul, 23ul, 53ul, 97ul, 193ul, 389ul, 769ul, 1543ul, 3079ul, 6151ul, 12289ul, 24593ul, 49157ul, 98317ul, 196613ul, 393241ul, 786433ul, 1572869ul, 3145739ul, 6291469ul, 12582917ul, 25165843ul, 50331653ul, 100663319ul, 201326611ul, 402653189ul, 805306457ul, 1610612741ul, 3221225473ul, 4294967291ul }; return &_stl_prime_list[0]; } NOTE: _stl_next_prime has the only calls to _get_stl_prime_list that = exist in the source code. The details for what is going on follow... There are 7 instances of get_stl_prime_list's code in my = /usr/local/bin/ctest, each with differing %r2 offsets for differing %r2 = values to allow finding appropriate _stl_prime_list addresses in various = places that include the header file. Each code instance from my build's = /usr/local/bin/ctest is shown below. (Note that the = ._ZN5cmsysL18get_stl_prime_listEv name does not vary despite the = distinct addresses.) But there is only 1 instance of _stl_next_prime's code in = /usr/local/bin/ctest, also shown below. This routine directly calls the = first of the ._ZN5cmsysL18get_stl_prime_listEv routines below, = effectively forcing the %r2 offset from that code to always be used = --and so generating garbage addresses for 6 of the 7 static contexts. 6 of the ._ZN5cmsysL18get_stl_prime_listEv's are completely unused. But most of the initial usage of _stl_next_prime in execution order = happens to have the %r2 value that goes with the first = ._ZN5cmsysL18get_stl_prime_listEv routine. That is why = /usr/local/bin/ctest dies as late as it does. I have observed the indicated behavior leading up to the crash under gdb = as well. 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101751c4 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101751c8 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101751cc <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2976(r2) 00000000101751d0 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101751d4 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101751d8 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101751dc <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101751e0 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101751e4 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101751e8 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001017c028 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001017c02c <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001017c030 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001017c034 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-2720(r2) 000000001017c038 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001017c03c <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001017c040 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001017c044 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001017c048 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001017c04c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001017c050 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000101f4ae8 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000101f4aec <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000101f4af0 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000101f4af4 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,2088(r2) 00000000101f4af8 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000101f4afc <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000101f4b00 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000101f4b04 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000101f4b08 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000101f4b0c <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000101f4b10 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001029161c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 0000000010291620 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 0000000010291624 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 0000000010291628 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,11344(r2) 000000001029162c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010291630 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010291634 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010291638 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001029163c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010291640 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010291644 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000103cde60 <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000103cde64 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000103cde68 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000103cde6c <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-32728(r2) 00000000103cde70 <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 00000000103cde74 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 00000000103cde78 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 00000000103cde7c <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 00000000103cde80 <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 00000000103cde84 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 00000000103cde88 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 000000001041bf4c <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 000000001041bf50 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 000000001041bf54 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 000000001041bf58 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-26608(r2) 000000001041bf5c <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 000000001041bf60 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 000000001041bf64 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 000000001041bf68 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 000000001041bf6c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 000000001041bf70 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 000000001041bf74 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) 00000000104719ec <._ZN5cmsysL18get_stl_prime_listEv> std r31,-8(r1) 00000000104719f0 <._ZN5cmsysL18get_stl_prime_listEv+0x4> stdu = r1,-64(r1) 00000000104719f4 <._ZN5cmsysL18get_stl_prime_listEv+0x8> mr r31,r1 00000000104719f8 <._ZN5cmsysL18get_stl_prime_listEv+0xc> ld = r0,-21280(r2) 00000000104719fc <._ZN5cmsysL18get_stl_prime_listEv+0x10> mr r3,r0 0000000010471a00 <._ZN5cmsysL18get_stl_prime_listEv+0x14> ld = r1,0(r1) 0000000010471a04 <._ZN5cmsysL18get_stl_prime_listEv+0x18> ld = r31,-8(r1) 0000000010471a08 <._ZN5cmsysL18get_stl_prime_listEv+0x1c> blr 0000000010471a0c <._ZN5cmsysL18get_stl_prime_listEv+0x20> .long 0x0 0000000010471a10 <._ZN5cmsysL18get_stl_prime_listEv+0x24> .long 0x90000 0000000010471a14 <._ZN5cmsysL18get_stl_prime_listEv+0x28> lwz = r0,1(r1) And here is the only _stl_next_prime routine: 0000000010176174 <._ZN5cmsys15_stl_next_primeEm> mflr r0 0000000010176178 <._ZN5cmsys15_stl_next_primeEm+0x4> std r31,-8(r1) 000000001017617c <._ZN5cmsys15_stl_next_primeEm+0x8> std r0,16(r1) 0000000010176180 <._ZN5cmsys15_stl_next_primeEm+0xc> stdu r1,-176(r1) 0000000010176184 <._ZN5cmsys15_stl_next_primeEm+0x10> mr r31,r1 0000000010176188 <._ZN5cmsys15_stl_next_primeEm+0x14> std = r3,224(r31) 000000001017618c <._ZN5cmsys15_stl_next_primeEm+0x18> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 0000000010176190 <._ZN5cmsys15_stl_next_primeEm+0x1c> mr r0,r3 0000000010176194 <._ZN5cmsys15_stl_next_primeEm+0x20> std = r0,128(r31) 0000000010176198 <._ZN5cmsys15_stl_next_primeEm+0x24> bl = 00000000101751c0 <._ZN5cmsysL18get_stl_prime_listEv> 000000001017619c <._ZN5cmsys15_stl_next_primeEm+0x28> mr r9,r3 00000000101761a0 <._ZN5cmsys15_stl_next_primeEm+0x2c> addi r0,r9,248 00000000101761a4 <._ZN5cmsys15_stl_next_primeEm+0x30> std = r0,120(r31) 00000000101761a8 <._ZN5cmsys15_stl_next_primeEm+0x34> ld = r3,128(r31) 00000000101761ac <._ZN5cmsys15_stl_next_primeEm+0x38> ld = r4,120(r31) 00000000101761b0 <._ZN5cmsys15_stl_next_primeEm+0x3c> addi r0,r31,224 00000000101761b4 <._ZN5cmsys15_stl_next_primeEm+0x40> mr r5,r0 00000000101761b8 <._ZN5cmsys15_stl_next_primeEm+0x44> bl = 0000000010176090 <._ZSt11lower_boundIPKmmET_S2_S2_RKT0_> 00000000101761bc <._ZN5cmsys15_stl_next_primeEm+0x48> crmove = 4*cr7+so,4*cr7+so 00000000101761c0 <._ZN5cmsys15_stl_next_primeEm+0x4c> mr r0,r3 00000000101761c4 <._ZN5cmsys15_stl_next_primeEm+0x50> std = r0,112(r31) 00000000101761c8 <._ZN5cmsys15_stl_next_primeEm+0x54> ld = r9,112(r31) 00000000101761cc <._ZN5cmsys15_stl_next_primeEm+0x58> ld = r0,120(r31) 00000000101761d0 <._ZN5cmsys15_stl_next_primeEm+0x5c> cmpd cr7,r9,r0 00000000101761d4 <._ZN5cmsys15_stl_next_primeEm+0x60> bne- = cr7,00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> 00000000101761d8 <._ZN5cmsys15_stl_next_primeEm+0x64> ld = r9,120(r31) 00000000101761dc <._ZN5cmsys15_stl_next_primeEm+0x68> addi r9,r9,-8 00000000101761e0 <._ZN5cmsys15_stl_next_primeEm+0x6c> ld r9,0(r9) 00000000101761e4 <._ZN5cmsys15_stl_next_primeEm+0x70> std = r9,144(r31) 00000000101761e8 <._ZN5cmsys15_stl_next_primeEm+0x74> b = 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> 00000000101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld = r9,112(r31) 00000000101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9) 00000000101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80> std = r9,144(r31) 00000000101761f8 <._ZN5cmsys15_stl_next_primeEm+0x84> ld = r0,144(r31) 00000000101761fc <._ZN5cmsys15_stl_next_primeEm+0x88> mr r3,r0 0000000010176200 <._ZN5cmsys15_stl_next_primeEm+0x8c> ld r1,0(r1) 0000000010176204 <._ZN5cmsys15_stl_next_primeEm+0x90> ld r0,16(r1) 0000000010176208 <._ZN5cmsys15_stl_next_primeEm+0x94> mtlr r0 000000001017620c <._ZN5cmsys15_stl_next_primeEm+0x98> ld r31,-8(r1) 0000000010176210 <._ZN5cmsys15_stl_next_primeEm+0x9c> blr 0000000010176214 <._ZN5cmsys15_stl_next_primeEm+0xa0> .long 0x0 0000000010176218 <._ZN5cmsys15_stl_next_primeEm+0xa4> .long 0x90001 000000001017621c <._ZN5cmsys15_stl_next_primeEm+0xa8> lwz r0,1(r1) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 06:35 PM, Mark Millard wrote: Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cyan = "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 10 23:49:48 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9EEEE4D; Tue, 10 Mar 2015 23:49:48 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (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 484407F7; Tue, 10 Mar 2015 23:49:48 +0000 (UTC) Received: by labgm9 with SMTP id gm9so5245024lab.11; Tue, 10 Mar 2015 16:49:46 -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=kUAVfzmpdCsVcb8oV+k3MYV22b8DOlB/mgMSjLUwKvc=; b=ifwBDzRzziUfYdIbIfCQaYR1sorivxyZFUxkvY4hfbN/jkimaPgNH0UyYexhxHhRUF rfMcmP5cKfGlD99cIBUOtrf2PMVwPe7BdgsPVC24O4UNnMG6t75d56nf/QjykLGZF9xc U66Hd9cRoCwOJj2hxqPM88gwgmoOCuRf4+p/spPZNnuS/+Ql6uSjDS9ty2yUwwRs60BY k0CS0g1tECrx9OBt248wBine/ZaShfEFUBuwKe+YcRYPHFw6/lw1aNsYg5tekXSCxod7 Xe+oF+d3fBe6JIQP6+QqMkRu0zesN818NqAaWXTYWWN+E3I0WAvssAJrj40RYRyaQij4 Y84g== MIME-Version: 1.0 X-Received: by 10.112.26.209 with SMTP id n17mr27359675lbg.84.1426031386313; Tue, 10 Mar 2015 16:49:46 -0700 (PDT) Sender: crodr001@gmail.com Received: by 10.112.82.164 with HTTP; Tue, 10 Mar 2015 16:49:46 -0700 (PDT) In-Reply-To: References: <1857A2A3-0C19-4F52-BCAF-6C72FE7D8DF3@FreeBSD.org> Date: Tue, 10 Mar 2015 16:49:46 -0700 X-Google-Sender-Auth: rVsrEcvOk3bD3tRQrOibIMa_O5g Message-ID: Subject: Re: Failed to build with external toolchain From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-testing@freebsd.org" , freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 23:49:49 -0000 On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric wrote: > On 07 Mar 2015, at 21:12, Craig Rodrigues wrote: > > I ran the build again and this time I am getting errors about undefined > > symbol utimensat(): > > > > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/14/console > > > > Any ideas? > > It's linking against the wrong libc, the one from the FreeBSD-10 host > system, which does not have utimensat(): > > --- cp --- > /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem > /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include > -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib > -O2 -pipe -DVM_AND_BUFFER_CACHE_SYNCHRONIZED -D_ACL_PRIVATE -std=gnu99 > -fstack-protector -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 -o cp cp.o > utils.o > [...] > utils.o: In function `setfile': > utils.c:(.text+0x83): undefined reference to `utimensat' > utils.c:(.text+0x1ce): undefined reference to `utimensat' > utils.c:(.text+0x38c): undefined reference to `utimensat' > collect2: error: ld returned 1 exit status > > There should probably be a --sysroot flag in there, pointing to the > ${WORLDTMP} built during the earlier stages. > > For some reason, this flag is not added for gcc, in Makefile.inc1. No > idea why that was done. > Oh, OK. So if I set CROSS_TOOLCHAIN=amd64-gcc, (1) /usr/local/share/toolchains/amd64-gcc.mk is included (2) X_COMPILER_TYPE=gcc is defined in (1) (3) This code is hit in Makefile.inc1: .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11 -L${WORLDTMP}/../lib/libc++ DEPFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 .else TARGET_ABI?= unknown TARGET_TRIPLE?= ${TARGET_ARCH:C/amd64/x86_64/}-${TARGET_ABI}-freebsd11.0 XCFLAGS+= -target ${TARGET_TRIPLE} XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS} So does this mean that --sysroot is not set? Should it be? -- Craig From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 09:36:55 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B680832 for ; Thu, 12 Mar 2015 09:36: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 14D27AE2 for ; Thu, 12 Mar 2015 09:36:54 +0000 (UTC) Received: (qmail 19348 invoked from network); 12 Mar 2015 09:36:53 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Mar 2015 09:36:53 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 05:36:53 -0400 (EDT) Received: (qmail 30965 invoked from network); 12 Mar 2015 09:36:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Mar 2015 09:36:53 -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 6AA591C43A2; Thu, 12 Mar 2015 02:36:51 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue Message-Id: <764C9B46-5AF9-46D0-AE9E-BE52809DA1D7@dsl-only.net> Date: Thu, 12 Mar 2015 02:36:50 -0700 To: FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 09:36:55 -0000 Basic context for the observation (powerpc64 example): # freebsd-version -ku; uname -a 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 As COMPILER_FEATURES context first I note that bsd.compiler.mk uses the = rule... .if ${COMPILER_TYPE} =3D=3D "clang" || \ (${COMPILER_TYPE} =3D=3D "gcc" && ${COMPILER_VERSION} >=3D = 40800) COMPILER_FEATURES=3D c++11 .else COMPILER_FEATURES=3D .endif So powerpc/powerpc64 ends up with COMPILER_FEATURES being empty unless = COMPILER_TYPE has been forced to be "clang" or ${CC} already is clang = based. But src.opts.mk will never indicate to build clang when = !${COMPILER_FEATURES:Mc++11} : that logic has priority over things like = ${__T:Mpowerpc*} tests... .include .if !${COMPILER_FEATURES:Mc++11} # If the compiler is not C++11 capable, disable clang and use gcc = instead. __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC .elif ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" # On x86, clang is enabled, and will be installed as the default cc. __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC __DEFAULT_NO_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX .elif ${__TT} =3D=3D "arm" && ${__T:Marm*eb*} =3D=3D "" # On little-endian arm, clang is enabled, and it is installed as the = default # cc, but since gcc is unable to build the full clang, disable it by = default. __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_IS_CC __DEFAULT_NO_OPTIONS+=3DCLANG_FULL GCC GCC_BOOTSTRAP GNUCXX .elif ${__T:Mpowerpc*} # On powerpc, clang is enabled, but gcc is installed as the default cc. __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX __DEFAULT_NO_OPTIONS+=3DCLANG_BOOTSTRAP CLANG_IS_CC .else # Everything else disables clang, and uses gcc instead. __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC .endif By contrast the old bsd.own.mk logic from 10.1-STABLE did not depend on = testing !${COMPILER_FEATURES:Mc++11} (or analogous) before deciding for = powerpc/powerpc64... # Clang is only for x86, powerpc and little-endian arm right now, by = default. .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" || ${__T:Mpowerpc*} __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL .elif ${__T} =3D=3D "arm" || ${__T} =3D=3D "armv6" __DEFAULT_YES_OPTIONS+=3DCLANG # GCC is unable to build the full clang on arm, disable it by default. __DEFAULT_NO_OPTIONS+=3DCLANG_FULL .else __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_FULL .endif # Clang the default system compiler only on little-endian arm and x86. .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "arm" || ${__T} =3D=3D = "armv6" || \ ${__T} =3D=3D "i386" __DEFAULT_YES_OPTIONS+=3DCLANG_IS_CC # The pc98 bootloader requires gcc to build and so we must leave gcc = enabled # for pc98 for now. .if ${__TT} =3D=3D "pc98" __DEFAULT_NO_OPTIONS+=3DGNUCXX __DEFAULT_YES_OPTIONS+=3DGCC .else __DEFAULT_NO_OPTIONS+=3DGCC GNUCXX .endif .else # If clang is not cc, then build gcc by default __DEFAULT_NO_OPTIONS+=3DCLANG_IS_CC __DEFAULT_YES_OPTIONS+=3DGCC # And if g++ is c++, build the rest of the GNU C++ stack .if defined(WITHOUT_CXX) __DEFAULT_NO_OPTIONS+=3DGNUCXX .else __DEFAULT_YES_OPTIONS+=3DGNUCXX .endif .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 09:36:55 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8BA46834 for ; Thu, 12 Mar 2015 09:36: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 14C2AAE1 for ; Thu, 12 Mar 2015 09:36:54 +0000 (UTC) Received: (qmail 8161 invoked from network); 12 Mar 2015 09:36:53 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Mar 2015 09:36:53 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 05:36:53 -0400 (EDT) Received: (qmail 31772 invoked from network); 12 Mar 2015 09: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; 12 Mar 2015 09:36:52 -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 E3DA51C439E; Thu, 12 Mar 2015 02:36:50 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue Message-Id: Date: Thu, 12 Mar 2015 02:36:50 -0700 To: FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 09:36:55 -0000 Basic context for the observation (powerpc64 example): # freebsd-version -ku; uname -a 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 As COMPILER_FEATURES context first I note that bsd.compiler.mk uses the = rule... .if ${COMPILER_TYPE} =3D=3D "clang" || \ (${COMPILER_TYPE} =3D=3D "gcc" && ${COMPILER_VERSION} >=3D = 40800) COMPILER_FEATURES=3D c++11 .else COMPILER_FEATURES=3D .endif So powerpc/powerpc64 ends up with COMPILER_FEATURES being empty unless = COMPILER_TYPE has been forced to be "clang" or ${CC} already is clang = based. But src.opts.mk will never indicate to build clang when = !${COMPILER_FEATURES:Mc++11} : that logic has priority over things like = ${__T:Mpowerpc*} tests... .include .if !${COMPILER_FEATURES:Mc++11} # If the compiler is not C++11 capable, disable clang and use gcc = instead. __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC .elif ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" # On x86, clang is enabled, and will be installed as the default cc. __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC __DEFAULT_NO_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX .elif ${__TT} =3D=3D "arm" && ${__T:Marm*eb*} =3D=3D "" # On little-endian arm, clang is enabled, and it is installed as the = default # cc, but since gcc is unable to build the full clang, disable it by = default. __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_IS_CC __DEFAULT_NO_OPTIONS+=3DCLANG_FULL GCC GCC_BOOTSTRAP GNUCXX .elif ${__T:Mpowerpc*} # On powerpc, clang is enabled, but gcc is installed as the default cc. __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX __DEFAULT_NO_OPTIONS+=3DCLANG_BOOTSTRAP CLANG_IS_CC .else # Everything else disables clang, and uses gcc instead. __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC .endif By contrast the old bsd.own.mk logic from 10.1-STABLE did not depend on = testing !${COMPILER_FEATURES:Mc++11} (or analogous) before deciding for = powerpc/powerpc64... # Clang is only for x86, powerpc and little-endian arm right now, by = default. .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" || ${__T:Mpowerpc*} __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL .elif ${__T} =3D=3D "arm" || ${__T} =3D=3D "armv6" __DEFAULT_YES_OPTIONS+=3DCLANG # GCC is unable to build the full clang on arm, disable it by default. __DEFAULT_NO_OPTIONS+=3DCLANG_FULL .else __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_FULL .endif # Clang the default system compiler only on little-endian arm and x86. .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "arm" || ${__T} =3D=3D = "armv6" || \ ${__T} =3D=3D "i386" __DEFAULT_YES_OPTIONS+=3DCLANG_IS_CC # The pc98 bootloader requires gcc to build and so we must leave gcc = enabled # for pc98 for now. .if ${__TT} =3D=3D "pc98" __DEFAULT_NO_OPTIONS+=3DGNUCXX __DEFAULT_YES_OPTIONS+=3DGCC .else __DEFAULT_NO_OPTIONS+=3DGCC GNUCXX .endif .else # If clang is not cc, then build gcc by default __DEFAULT_NO_OPTIONS+=3DCLANG_IS_CC __DEFAULT_YES_OPTIONS+=3DGCC # And if g++ is c++, build the rest of the GNU C++ stack .if defined(WITHOUT_CXX) __DEFAULT_NO_OPTIONS+=3DGNUCXX .else __DEFAULT_YES_OPTIONS+=3DGNUCXX .endif .endif =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 12:00:44 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA7A05CC for ; Thu, 12 Mar 2015 12:00:44 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (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 B3AE4D54 for ; Thu, 12 Mar 2015 12:00:44 +0000 (UTC) Received: by pabrd3 with SMTP id rd3so20039628pab.6 for ; Thu, 12 Mar 2015 05:00:38 -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=jN/Nqrerb8lXkznM/zqAiRsI9Q5ftmHWAgeZOlBnBN8=; b=axAWXQpYaUm/dHLyxye8unkiDkWz0S+dR9G6O4o7Mb/X/lduPihFWBluZawnmgAAX6 jMu8YD2dcMXS+HUgQTPvXg0z1Ch/uIDSaj5oAEGKwAf8kJ4BL+CX3K5t2R+7aSzCuG9o 1ofUNmtNsEBQI/M73eQPr/Pm9xPL9z7HFd5GE3cDP0+elZ4xZXJGXN4rN/juSeMDBJzZ S3tmIxmLY2nAQ9MEaRcKgaP4bSV/l84Y4bzcBGnA3bVghUW54yMmbLFkC0tqu5g4Ro89 P7f4KF1SVZkp2vioMoa6tk9VH1KTL4DYyJqXv2e1qiUB8Zlrn/fbeb4DMilEAWeCYU4F LL7g== X-Gm-Message-State: ALoCoQlZ/w4s2do6YVYBQoAEcx4HI6OL5EZTX2vM0tmHq07gurGniUTlwjQb9teoY2TQkNj5LH+n X-Received: by 10.66.121.129 with SMTP id lk1mr28256396pab.155.1426161638529; Thu, 12 Mar 2015 05:00:38 -0700 (PDT) Received: from [192.168.18.23] (221x253x176x170.ap221.ftth.ucom.ne.jp. [221.253.176.170]) by mx.google.com with ESMTPSA id se2sm10724528pac.38.2015.03.12.05.00.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 05:00:37 -0700 (PDT) Sender: Warner Losh Subject: Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6A1F383F-178D-40FC-8401-540EAFC36504"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: Date: Thu, 12 Mar 2015 21:00:33 +0900 Message-Id: References: To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 12:00:45 -0000 --Apple-Mail=_6A1F383F-178D-40FC-8401-540EAFC36504 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 12, 2015, at 6:36 PM, Mark Millard wrote: >=20 > Basic context for the observation (powerpc64 example): >=20 > # freebsd-version -ku; uname -a > 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 >=20 >=20 > As COMPILER_FEATURES context first I note that bsd.compiler.mk uses = the rule... >=20 > .if ${COMPILER_TYPE} =3D=3D "clang" || \ > (${COMPILER_TYPE} =3D=3D "gcc" && ${COMPILER_VERSION} >=3D = 40800) > COMPILER_FEATURES=3D c++11 > .else > COMPILER_FEATURES=3D > .endif >=20 > So powerpc/powerpc64 ends up with COMPILER_FEATURES being empty unless = COMPILER_TYPE has been forced to be "clang" or ${CC} already is clang = based. >=20 > But src.opts.mk will never indicate to build clang when = !${COMPILER_FEATURES:Mc++11} : that logic has priority over things like = ${__T:Mpowerpc*} tests=E2=80=A6 Clang can only be built by a new gcc or clang. Old gcc can=E2=80=99t = build it, so if you don=E2=80=99t have a new gcc, you can=E2=80=99t = build clang. The default compiler was gcc on 10.1. There likely should = be an UPDATING entry to make this clear. Warner > .include > .if !${COMPILER_FEATURES:Mc++11} > # If the compiler is not C++11 capable, disable clang and use gcc = instead. > __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC > .elif ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" > # On x86, clang is enabled, and will be installed as the default cc. > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC > __DEFAULT_NO_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX > .elif ${__TT} =3D=3D "arm" && ${__T:Marm*eb*} =3D=3D "" > # On little-endian arm, clang is enabled, and it is installed as the = default > # cc, but since gcc is unable to build the full clang, disable it by = default. > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_IS_CC > __DEFAULT_NO_OPTIONS+=3DCLANG_FULL GCC GCC_BOOTSTRAP GNUCXX > .elif ${__T:Mpowerpc*} > # On powerpc, clang is enabled, but gcc is installed as the default = cc. > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX > __DEFAULT_NO_OPTIONS+=3DCLANG_BOOTSTRAP CLANG_IS_CC > .else > # Everything else disables clang, and uses gcc instead. > __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC > .endif >=20 >=20 >=20 > By contrast the old bsd.own.mk logic from 10.1-STABLE did not depend = on testing !${COMPILER_FEATURES:Mc++11} (or analogous) before deciding = for powerpc/powerpc64... >=20 > # Clang is only for x86, powerpc and little-endian arm right now, by = default. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" || ${__T:Mpowerpc*} > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL > .elif ${__T} =3D=3D "arm" || ${__T} =3D=3D "armv6" > __DEFAULT_YES_OPTIONS+=3DCLANG > # GCC is unable to build the full clang on arm, disable it by default. > __DEFAULT_NO_OPTIONS+=3DCLANG_FULL > .else > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_FULL > .endif > # Clang the default system compiler only on little-endian arm and x86. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "arm" || ${__T} =3D=3D = "armv6" || \ > ${__T} =3D=3D "i386" > __DEFAULT_YES_OPTIONS+=3DCLANG_IS_CC > # The pc98 bootloader requires gcc to build and so we must leave gcc = enabled > # for pc98 for now. > .if ${__TT} =3D=3D "pc98" > __DEFAULT_NO_OPTIONS+=3DGNUCXX > __DEFAULT_YES_OPTIONS+=3DGCC > .else > __DEFAULT_NO_OPTIONS+=3DGCC GNUCXX > .endif > .else > # If clang is not cc, then build gcc by default > __DEFAULT_NO_OPTIONS+=3DCLANG_IS_CC > __DEFAULT_YES_OPTIONS+=3DGCC > # And if g++ is c++, build the rest of the GNU C++ stack > .if defined(WITHOUT_CXX) > __DEFAULT_NO_OPTIONS+=3DGNUCXX > .else > __DEFAULT_YES_OPTIONS+=3DGNUCXX > .endif > .endif >=20 >=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" --Apple-Mail=_6A1F383F-178D-40FC-8401-540EAFC36504 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 iQIcBAEBCgAGBQJVAX/hAAoJEGwc0Sh9sBEAwgIQANRi0LrupCGQz4G5KErQJxZy bj8D1ePk4nXsoU/wZFqkzBhblVICVINYMz9fp/qo0qCfU1gqvrwS28wl9vX+igSP WsNF/gOy294zfGhsz+Aw4BDXyYIFpYzFzzv7HFHYRasLmdSvVRg7p789ahMv6e1U FaopGD/VKA28CFjeTHO4Q0OED44QPhdEaoPDM+GY3X8wWGNwTrXkrt7vK5yLnlsi u5OlgTERpM4mUGaIcGLsNAGSaXRlDg2bsDCduoL7wRS/KWj7VHEVogzokDuEkIxm y05G6OP+1XolQOV46y1Fmep1ojhTzwOmsVqp3wGLlCbg16E7bD4pTSfyfU1s6n0F MwOqI6ih5v5xCMPmgIVAdwNXpWhkmKbMfkwJkn/RIYXcEFTwLwbADYhnnkuUNmf0 YRxSl8wIh2YQFV0SeSv/0LW5wk9s9N5TLBaPvtY4vQ0+UWm/v9JidE0r0kXAcYpk F3MaMNoDbnrfpHDbN438VYVfaVg0LnEDWVIoa5PFi7UePNx9covi5+fSKCbW7yjZ tWtOnHGnyTJKURoAr+8/PeyLUWwfJ9M8x5qy0UIrXm9Sl9s/dSMPSc6SiVCFjkWm ZzRTZgay229wKNx+m0rHQ6J8Kmde8qXaU5D7cZ36KlWlsOg6jQWmf8Xim7vv7N/9 5Suc1gfvaL4f6gCI++Gj =xlm5 -----END PGP SIGNATURE----- --Apple-Mail=_6A1F383F-178D-40FC-8401-540EAFC36504-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 17:01:33 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B84B9DB for ; Thu, 12 Mar 2015 17:01:33 +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 1F5D598F for ; Thu, 12 Mar 2015 17:01:32 +0000 (UTC) Received: (qmail 32257 invoked from network); 12 Mar 2015 17:01:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 12 Mar 2015 17:01:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 13:01:31 -0400 (EDT) Received: (qmail 16018 invoked from network); 12 Mar 2015 17:01:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Mar 2015 17:01: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 23CA31C43AD; Thu, 12 Mar 2015 10:01:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue From: Mark Millard In-Reply-To: Date: Thu, 12 Mar 2015 10:01:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A17FBA1-9499-4862-83DF-1C4010D96003@dsl-only.net> References: To: Warner Losh X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:01:33 -0000 Well there is an entry but when I read it I did not find it clear about = the 10.x status. I think the implication is that the 9.x paragraph also applies to 10.x: On 9.x [and 10.x] installations where clang is enabled by = default, e.g. on x86 and powerpc, libc++ will not be enabled by default, so libc++ should = be built (with clang) and installed first. If both clang and = libc++ are missing, build clang first, then use it to build libc++. =3D=3D=3D Mark Millard markmi@dsl-only.net On 2015-Mar-12, at 05:00 AM, Warner Losh wrote: > On Mar 12, 2015, at 6:36 PM, Mark Millard wrote: >=20 > Basic context for the observation (powerpc64 example): >=20 > # freebsd-version -ku; uname -a > 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 >=20 >=20 > As COMPILER_FEATURES context first I note that bsd.compiler.mk uses = the rule... >=20 > .if ${COMPILER_TYPE} =3D=3D "clang" || \ > (${COMPILER_TYPE} =3D=3D "gcc" && ${COMPILER_VERSION} >=3D = 40800) > COMPILER_FEATURES=3D c++11 > .else > COMPILER_FEATURES=3D > .endif >=20 > So powerpc/powerpc64 ends up with COMPILER_FEATURES being empty unless = COMPILER_TYPE has been forced to be "clang" or ${CC} already is clang = based. >=20 > But src.opts.mk will never indicate to build clang when = !${COMPILER_FEATURES:Mc++11} : that logic has priority over things like = ${__T:Mpowerpc*} tests=E2=80=A6 Clang can only be built by a new gcc or clang. Old gcc can=E2=80=99t = build it, so if you don=E2=80=99t have a new gcc, you can=E2=80=99t = build clang. The default compiler was gcc on 10.1. There likely should = be an UPDATING entry to make this clear. Warner > .include > .if !${COMPILER_FEATURES:Mc++11} > # If the compiler is not C++11 capable, disable clang and use gcc = instead. > __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC > .elif ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" > # On x86, clang is enabled, and will be installed as the default cc. > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC > __DEFAULT_NO_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX > .elif ${__TT} =3D=3D "arm" && ${__T:Marm*eb*} =3D=3D "" > # On little-endian arm, clang is enabled, and it is installed as the = default > # cc, but since gcc is unable to build the full clang, disable it by = default. > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_IS_CC > __DEFAULT_NO_OPTIONS+=3DCLANG_FULL GCC GCC_BOOTSTRAP GNUCXX > .elif ${__T:Mpowerpc*} > # On powerpc, clang is enabled, but gcc is installed as the default = cc. > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX > __DEFAULT_NO_OPTIONS+=3DCLANG_BOOTSTRAP CLANG_IS_CC > .else > # Everything else disables clang, and uses gcc instead. > __DEFAULT_YES_OPTIONS+=3DGCC GCC_BOOTSTRAP GNUCXX > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC > .endif >=20 >=20 >=20 > By contrast the old bsd.own.mk logic from 10.1-STABLE did not depend = on testing !${COMPILER_FEATURES:Mc++11} (or analogous) before deciding = for powerpc/powerpc64... >=20 > # Clang is only for x86, powerpc and little-endian arm right now, by = default. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "i386" || ${__T:Mpowerpc*} > __DEFAULT_YES_OPTIONS+=3DCLANG CLANG_FULL > .elif ${__T} =3D=3D "arm" || ${__T} =3D=3D "armv6" > __DEFAULT_YES_OPTIONS+=3DCLANG > # GCC is unable to build the full clang on arm, disable it by default. > __DEFAULT_NO_OPTIONS+=3DCLANG_FULL > .else > __DEFAULT_NO_OPTIONS+=3DCLANG CLANG_FULL > .endif > # Clang the default system compiler only on little-endian arm and x86. > .if ${__T} =3D=3D "amd64" || ${__T} =3D=3D "arm" || ${__T} =3D=3D = "armv6" || \ > ${__T} =3D=3D "i386" > __DEFAULT_YES_OPTIONS+=3DCLANG_IS_CC > # The pc98 bootloader requires gcc to build and so we must leave gcc = enabled > # for pc98 for now. > .if ${__TT} =3D=3D "pc98" > __DEFAULT_NO_OPTIONS+=3DGNUCXX > __DEFAULT_YES_OPTIONS+=3DGCC > .else > __DEFAULT_NO_OPTIONS+=3DGCC GNUCXX > .endif > .else > # If clang is not cc, then build gcc by default > __DEFAULT_NO_OPTIONS+=3DCLANG_IS_CC > __DEFAULT_YES_OPTIONS+=3DGCC > # And if g++ is c++, build the rest of the GNU C++ stack > .if defined(WITHOUT_CXX) > __DEFAULT_NO_OPTIONS+=3DGNUCXX > .else > __DEFAULT_YES_OPTIONS+=3DGNUCXX > .endif > .endif >=20 >=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" From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 17:04:59 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60DF7BA8; Thu, 12 Mar 2015 17:04:59 +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 445489D1; Thu, 12 Mar 2015 17:04:59 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2CH4pOQ000804 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Mar 2015 10:04:51 -0700 Message-ID: <5501C732.7050502@freebsd.org> Date: Thu, 12 Mar 2015 10:04:50 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML Subject: Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue References: <7A17FBA1-9499-4862-83DF-1C4010D96003@dsl-only.net> In-Reply-To: <7A17FBA1-9499-4862-83DF-1C4010D96003@dsl-only.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVbbWFrQH+mrWUWqfnxGGAhhx+gTbLQFJvbtevgCiP1qJpDL0a6CpB4XClK2MsImII036B6PLLvfZ0VUazFPjoJy3h5iZ2dV0Ho= X-Sonic-ID: C;gOmB5dnI5BGiEr5YxQPdhw== M;9AnP5dnI5BGiEr5YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:04:59 -0000 This is not the right one. That is related to clang 3.4. The issue is that clang 3.5+ require a C++11 compiler to build. GCC 4.2 is not a C++11 compiler and so the clang build was disabled. This makes the upgrade path when clang becomes the default compiler a little bumpy, but that did not seem to be a reason to hold off on the 3.5 upgrade across the board. -Nathan On 03/12/15 10:01, Mark Millard wrote: > Well there is an entry but when I read it I did not find it clear about the 10.x status. > > I think the implication is that the 9.x paragraph also applies to 10.x: > > On 9.x [and 10.x] installations where clang is enabled by default, e.g. on x86 and > powerpc, libc++ will not be enabled by default, so libc++ should be > built (with clang) and installed first. If both clang and libc++ are > missing, build clang first, then use it to build libc++. > > === > Mark Millard > markmi@dsl-only.net > > On 2015-Mar-12, at 05:00 AM, Warner Losh wrote: > > >> On Mar 12, 2015, at 6:36 PM, Mark Millard wrote: >> >> Basic context for the observation (powerpc64 example): >> >> # freebsd-version -ku; uname -a >> 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 >> >> >> As COMPILER_FEATURES context first I note that bsd.compiler.mk uses the rule... >> >> .if ${COMPILER_TYPE} == "clang" || \ >> (${COMPILER_TYPE} == "gcc" && ${COMPILER_VERSION} >= 40800) >> COMPILER_FEATURES= c++11 >> .else >> COMPILER_FEATURES= >> .endif >> >> So powerpc/powerpc64 ends up with COMPILER_FEATURES being empty unless COMPILER_TYPE has been forced to be "clang" or ${CC} already is clang based. >> >> But src.opts.mk will never indicate to build clang when !${COMPILER_FEATURES:Mc++11} : that logic has priority over things like ${__T:Mpowerpc*} tests… > Clang can only be built by a new gcc or clang. Old gcc can’t build it, so if you don’t have a new gcc, you can’t build clang. The default compiler was gcc on 10.1. There likely should be an UPDATING entry to make this clear. > > Warner > > >> .include >> .if !${COMPILER_FEATURES:Mc++11} >> # If the compiler is not C++11 capable, disable clang and use gcc instead. >> __DEFAULT_YES_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX >> __DEFAULT_NO_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC >> .elif ${__T} == "amd64" || ${__T} == "i386" >> # On x86, clang is enabled, and will be installed as the default cc. >> __DEFAULT_YES_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC >> __DEFAULT_NO_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX >> .elif ${__TT} == "arm" && ${__T:Marm*eb*} == "" >> # On little-endian arm, clang is enabled, and it is installed as the default >> # cc, but since gcc is unable to build the full clang, disable it by default. >> __DEFAULT_YES_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_IS_CC >> __DEFAULT_NO_OPTIONS+=CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX >> .elif ${__T:Mpowerpc*} >> # On powerpc, clang is enabled, but gcc is installed as the default cc. >> __DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL GCC GCC_BOOTSTRAP GNUCXX >> __DEFAULT_NO_OPTIONS+=CLANG_BOOTSTRAP CLANG_IS_CC >> .else >> # Everything else disables clang, and uses gcc instead. >> __DEFAULT_YES_OPTIONS+=GCC GCC_BOOTSTRAP GNUCXX >> __DEFAULT_NO_OPTIONS+=CLANG CLANG_BOOTSTRAP CLANG_FULL CLANG_IS_CC >> .endif >> >> >> >> By contrast the old bsd.own.mk logic from 10.1-STABLE did not depend on testing !${COMPILER_FEATURES:Mc++11} (or analogous) before deciding for powerpc/powerpc64... >> >> # Clang is only for x86, powerpc and little-endian arm right now, by default. >> .if ${__T} == "amd64" || ${__T} == "i386" || ${__T:Mpowerpc*} >> __DEFAULT_YES_OPTIONS+=CLANG CLANG_FULL >> .elif ${__T} == "arm" || ${__T} == "armv6" >> __DEFAULT_YES_OPTIONS+=CLANG >> # GCC is unable to build the full clang on arm, disable it by default. >> __DEFAULT_NO_OPTIONS+=CLANG_FULL >> .else >> __DEFAULT_NO_OPTIONS+=CLANG CLANG_FULL >> .endif >> # Clang the default system compiler only on little-endian arm and x86. >> .if ${__T} == "amd64" || ${__T} == "arm" || ${__T} == "armv6" || \ >> ${__T} == "i386" >> __DEFAULT_YES_OPTIONS+=CLANG_IS_CC >> # The pc98 bootloader requires gcc to build and so we must leave gcc enabled >> # for pc98 for now. >> .if ${__TT} == "pc98" >> __DEFAULT_NO_OPTIONS+=GNUCXX >> __DEFAULT_YES_OPTIONS+=GCC >> .else >> __DEFAULT_NO_OPTIONS+=GCC GNUCXX >> .endif >> .else >> # If clang is not cc, then build gcc by default >> __DEFAULT_NO_OPTIONS+=CLANG_IS_CC >> __DEFAULT_YES_OPTIONS+=GCC >> # And if g++ is c++, build the rest of the GNU C++ stack >> .if defined(WITHOUT_CXX) >> __DEFAULT_NO_OPTIONS+=GNUCXX >> .else >> __DEFAULT_YES_OPTIONS+=GNUCXX >> .endif >> .endif >> >> >> === >> 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" > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" > From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 19:18:56 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CCF29A18 for ; Thu, 12 Mar 2015 19:18:56 +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 6AD4ABF9 for ; Thu, 12 Mar 2015 19:18:55 +0000 (UTC) Received: (qmail 16333 invoked from network); 12 Mar 2015 19:18:54 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Mar 2015 19:18:54 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 15:18:54 -0400 (EDT) Received: (qmail 9958 invoked from network); 12 Mar 2015 19:18:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Mar 2015 19:18:54 -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 ED777B1E001; Thu, 12 Mar 2015 12:18:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: On powerpc 11.0-CURRENT CROSS_TOOLCHAIN=powerpc64-gcc fails: clang-tblgen use attempted before it exists From: Mark Millard In-Reply-To: <89F97E94-AB9F-46C0-9AA2-C4D0680D64E7@dsl-only.net> Date: Thu, 12 Mar 2015 12:18:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <60F1C8B5-8621-452B-A6A3-DEE4B48B848D@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> To: Baptiste Daroussin X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 19:18:57 -0000 Basic context: $ 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) 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. While powerpc64-gcc (and so powerpc64-xtoolchain-gcc) fails to build = when portmaster'd on powerpc64 it does build on powerpc. So I portmaster'd powerpc64-xtoolchain-gcc in the powerpc (non-64) = 11.0-CURRENT context to attempt a "cross" compile back to powerpc... The problem: (Or is the below attempt a form of abuse of powerpc64-xtoolchain-gcc?) (Remember: no clang exists beforehand.) For... make CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain KERNCONF=3DGENERICvtsc = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc or make CROSS_TOOLCHAIN=3Dpowerpc64-gcc buildworld buildkernel = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc Either way the result fails to complete by attempting to use = clang-tblgen when it does not exist (yet?): > ... > -------------------------------------------------------------- > >>> 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 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. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 20:25:01 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9D2B3E0 for ; Thu, 12 Mar 2015 20:25:00 +0000 (UTC) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (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 B21FE68E for ; Thu, 12 Mar 2015 20:25:00 +0000 (UTC) Received: by pabrd3 with SMTP id rd3so23278303pab.6 for ; Thu, 12 Mar 2015 13:24:54 -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=ieonmVKX17a8NRXoTZVTKMgEstxDVgQ1BWsJDK6l9hw=; b=bcYx48mI9QG54vkUhwe9gFo6LhtuYpxsqQ9JOJlaZBhjFeI415OEXgVOLUPTbiUMEa Pk0BXWChzgwhHc5nEkOeM36LmPx7Irme30IqtbZd6IpT+/zk7iQRbVaj8f5PhPjRzGVy DT+8spTHIgaN/fdSY4Dud852euM/pW4mBfmAgEyvGtHugPpCJEtRn3xwZwV/+wIYK+CD eYwtH4IyEN50CN26zyQgcDAa9gNGAoMF9ZJqabbLvIYXL6SzPOY14qob8Pf1UMgRvP6w W10GMZXsUpi3vskubXFe7u6xRaTuvYvCC3MnC4wCXr7SjIyTsw+6P4EauC/Te6XRTJ5A L1Mw== X-Gm-Message-State: ALoCoQljzTnsOuws2K2uAEUoryVXRUxEonwYTJUezXVP29kXl6ab5sZzlU7EoRxMtL0+XcqCWjGl X-Received: by 10.67.1.164 with SMTP id bh4mr92239994pad.129.1426191893939; Thu, 12 Mar 2015 13:24:53 -0700 (PDT) Received: from [192.168.18.23] (221x253x176x170.ap221.ftth.ucom.ne.jp. [221.253.176.170]) by mx.google.com with ESMTPSA id kd9sm12495068pab.0.2015.03.12.13.24.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 13:24:53 -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=_CAED5CAA-62B4-4DF5-8C70-5792D51E8866"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: <60F1C8B5-8621-452B-A6A3-DEE4B48B848D@dsl-only.net> Date: Fri, 13 Mar 2015 05:24:50 +0900 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> To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 20:25:01 -0000 --Apple-Mail=_CAED5CAA-62B4-4DF5-8C70-5792D51E8866 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry to top post, but try adding WITH_CLANG=3Dt Warner > 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" --Apple-Mail=_CAED5CAA-62B4-4DF5-8C70-5792D51E8866 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 iQIcBAEBCgAGBQJVAfYSAAoJEGwc0Sh9sBEAMTAP/16D95l4qd9zahQXemf2R7CS sPNf1yfevmi1xdfGPBlNB6AyF+fxniTN3fptXSX642oh1cRRrbGhNE2+WW4KKcQi nRnw7bnJiR5wRdxTVU868Zug0CFYKabVYirqlUoWhdJ1IO3YEmx4Sp2KMT5SG8i2 Cl/3RL7wQ6wM33cprulqIEBax9/Ugi6pfWGHNobnI49qwOgXI/RoGjVxKekGtNUo OR/zs4VSg0qeCdnKmu9pQ0CjVVHyPm4yFIYE2sYfQ2txlTWxY3SxUkhQkYgmCja4 cbc1BKWn8N5xrPhxRJ7Swla/D8VDJ9i669LkQyDGu5dG8U6yvXg0UGUdM+HtgjKR CCFmF8fYTCRC2kQg6XX9u0GSpjgoi7MeiLV22bOf6jeKC8VHZLzYi6uiXs2ZTrdL XKmGzouO2zPvT/JnYb4IIyznR1LM5qKJRwV/02n1/FfG2gZ7Nlz48fuxtAVn7j8f J4pLOQN4T1xvBROIYgwyJRqqHVwGWR/zA5c8+c0BYUmIqTVg9LH9UHKk0H3DB9S1 R2a6GEQNqqZI3F2XhIFiGN35gySYLWAZbEb4LerC603pONivrXw+vqOUaZ2yqZcu AMRQzv/DlSi1riQtsmXFTb4spo9lpe50+9qThEuP15522eOdZviIcoenDY247qi/ oefi8kGuvJ+BkmILsrg7 =YYfI -----END PGP SIGNATURE----- --Apple-Mail=_CAED5CAA-62B4-4DF5-8C70-5792D51E8866-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 20:42:43 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6677B8D3 for ; Thu, 12 Mar 2015 20:42: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 1938291A for ; Thu, 12 Mar 2015 20:42:42 +0000 (UTC) Received: (qmail 19342 invoked from network); 12 Mar 2015 20:42:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Mar 2015 20:42:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 16:42:41 -0400 (EDT) Received: (qmail 29435 invoked from network); 12 Mar 2015 20:42:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Mar 2015 20:42:40 -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 C36CC1C43AC; Thu, 12 Mar 2015 13:42:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii 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: Date: Thu, 12 Mar 2015 13:42:38 -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> To: Warner Losh X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 20:42:43 -0000 Warner L. wrote about my attempt to use = rpc64-xtoolchain-gcc/powerpc64-gcc in a powerpc (non-64) context that = has no clang built: > Trying WITH_CLANG=3Dt ... So I did... make WITH_CLANG=3Dt CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc This results in a different failure (cc1plus not understanding the = -std=3Dc++11 option that it ends up being given): -------------------------------------------------------------- >>> 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=20 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" ... =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 01:24 PM, Warner Losh wrote: Sorry to top post, but try adding WITH_CLANG=3Dt Warner > 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" From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 21:40:21 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3CE25E3 for ; Thu, 12 Mar 2015 21:40:21 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (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 AA712E76 for ; Thu, 12 Mar 2015 21:40:21 +0000 (UTC) Received: by paceu11 with SMTP id eu11so23740337pac.4 for ; Thu, 12 Mar 2015 14:40:15 -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=vODuyVJyugDvvYd+l1WyQ5rE41lHpOSwhvRQZgSutB0=; b=dtxFZpG8I8i/WerBpUrk+zg5tHoMEvYkcpWQPi6ZuzvhLhXQS1bLUxRZYeuIc+hO/r WewpumXMsis1pOVvKtGejpKie1XTyDHed6YnRc2PCnCzf4NS2oqjxfYs/8zgv/RF3byo HyKwzyEXyu2pmTnn3iQJGMT31e8GQdpEMZbiQOBODnp8kLn4MOQ1PNIsoMNz+hOrmvGy G4HhZgSF8ZR5GMGZMQIkh0sjeL+7URqIijmQQdod3MYUowwlNknUDoeGwGFRIYjjcZXx fmRPgQBCQRsUy3m/f70Rj449jkSGzvyqj5CX0B2JCoqwDGgIBtybnK/8ARxB+r5bjkf+ X0Ew== X-Gm-Message-State: ALoCoQlfyoPWnz25nFi1GNlTSjfBQNjmzHSbbny1/UTQ+eJCC2eN3O3NKKdKPgFFJdFmbcmdbfkl X-Received: by 10.70.1.227 with SMTP id 3mr15712946pdp.110.1426195986387; Thu, 12 Mar 2015 14:33:06 -0700 (PDT) Received: from [192.168.18.23] (221x253x176x170.ap221.ftth.ucom.ne.jp. [221.253.176.170]) by mx.google.com with ESMTPSA id yt8sm58803pab.22.2015.03.12.14.33.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 14:33:05 -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=_5FB184A3-F259-451A-ABB9-6ECD41797338"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: Date: Fri, 13 Mar 2015 06:33:02 +0900 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> To: Mark Millard X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 21:40:22 -0000 --Apple-Mail=_5FB184A3-F259-451A-ABB9-6ECD41797338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 --Apple-Mail=_5FB184A3-F259-451A-ABB9-6ECD41797338 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 iQIcBAEBCgAGBQJVAgYPAAoJEGwc0Sh9sBEAFWYP/isWn9r/fxT3PPsZ0oJ8M8yr 8Ch0OcMhAEoC2EwxPcWYhbSad62Y8J5jfL9KeJCL4a5P05CJwOmL9fV2q+disMdk iybQDgNvurv+G80iFaoA5M8ApCbCb4ga4lKH+AwIfn7tpe//AnGOXWX08vdQcDsL h7WYg/NXUzxI40iuFKn8ktMKbdDrJn7QzNsPxxPjExWLlIBL6JJxJVgql8u9FdUM tNakEuhHqN/mkceq/MC0XfDacjyS3pgYwqRblprWhWlzbGoZKh0jHS+9oZAvqSeW EUO0U2BWe2LuT0Yo71ZNBYwCP7HC5EVMTFquCIDH94wykIQ+jy0nvbd9aWJHA8IR V5JfgJz66L6qXevNxGw9T0pRNtV42q/S66C/Tu9DHfX2MqFohk/rWOiP5040Jx/9 jVM3cbNH1XhbEZ5kgxvcIZPZpKfeSSHRdXOS5UbQ+Bt0g5j6LWTZ/H6i3FS8Zk5y qtNgmYpRwz536TNanZoZUcTS1LCv59P1l+T59sCZQndaUJ2zT4/0EnUBCrnp6rNq sQisjBpBkulQBXJy49IlvnqNwGSCVQ5aTb/35n6056xCC8TvyMQ9wLmwyRugcFDr 0M+kgKyBI2zuBkL2nEHt5iznY0gqGILO8zFf0e+cwjB4Avoh/Kgo8FhQdGpfnmon Afepsm2RC3hHSBa6RIvy =yJKN -----END PGP SIGNATURE----- --Apple-Mail=_5FB184A3-F259-451A-ABB9-6ECD41797338-- From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 22:13:53 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF111CD7 for ; Thu, 12 Mar 2015 22:13: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 62492281 for ; Thu, 12 Mar 2015 22:13:52 +0000 (UTC) Received: (qmail 6812 invoked from network); 12 Mar 2015 22:13:51 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 12 Mar 2015 22:13:51 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 18:13:51 -0400 (EDT) Received: (qmail 8449 invoked from network); 12 Mar 2015 22:13:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Mar 2015 22:13:50 -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 842FD1C439E; Thu, 12 Mar 2015 15:13:45 -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: Date: Thu, 12 Mar 2015 15:13:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <357555BE-7F87-4B25-95BE-43DD33CD8FE2@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> To: Warner Losh X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 22:13:53 -0000 Warner wrote: > Is cc1plus the g++ compiler that is installed on your bootstrapped = system, or is it the one that the powerpc64-gcc toolchain built? cc1plus = -v will help determine that. You may have to find it on your system = (there=E2=80=99s likely 2) and pass it the -std=3Dc++11 option to see = which of them fail. We may have a leak / problem with mkdep that your = unique setup is revealing. The below details indicate that gcc 4.2.1's /usr/libexec/cc1plus was in = use when the message about -std=3Dc++11 being unrecognized was generated = for "make WITH_CLANG=3Dt CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc". Details... # which cc1plus # So no cc1plus is in my default path: it is being found another way. Ingoring the /usr/src/... and /usr/obj/... paths that have a cc1plus... $ find / -name cc1plus -print /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus ... /usr/libexec/cc1plus ... No others. $ ls -FPal = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 14582156 Mar 12 10:25 = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 15771164 Mar 12 10:25 = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus* $ ls -FPal /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 6541860 Mar 10 23:21 /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 7115952 Mar 10 23:21 /usr/libexec/cc1plus* $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -v ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1/powerpc64-portbld-freebsd11.0" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1/backward" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/sys-include" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include-fixed End of search list. ^C $ /usr/libexec/cc1plus -v #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/backward /usr/include/gcc/4.2 /usr/include End of search list. ^C $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus = -std=3Dc++11 ^C $ /usr/libexec/cc1plus -std=3Dc++11 cc1plus: error: unrecognized command line option "-std=3Dc++11" ^C =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 02:33 PM, Warner Losh wrote: Thanks Mark. :( Is cc1plus the g++ compiler that is installed on your bootstrapped = system, or is it the one that the powerpc64-gcc toolchain built? cc1plus = -v will help determine that. You may have to find it on your system = (there=E2=80=99s likely 2) and pass it the -std=3Dc++11 option to see = which of them fail. We may have a leak / problem with mkdep that your = unique setup is revealing. Warner > On Mar 13, 2015, at 5:42 AM, Mark Millard wrote: >=20 > Warner L. wrote about my attempt to use = rpc64-xtoolchain-gcc/powerpc64-gcc in a powerpc (non-64) context that = has no clang built: >=20 >> Trying WITH_CLANG=3Dt ... >=20 > So I did... >=20 > make WITH_CLANG=3Dt CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >=20 > This results in a different failure (cc1plus not understanding the = -std=3Dc++11 option that it ends up being given): >=20 > -------------------------------------------------------------- >>>> stage 1.2: bootstrap tools > -------------------------------------------------------------- > ... > mkdep -f .depend -a = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support = -I. = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -std=3Dc++11 = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp > ... ... = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_os= tream.cpp > cc1plus: error: unrecognized command line option "-std=3Dc++11" > cc1plus: error: unrecognized command line option "-std=3Dc++11" > cc1plus: error: unrecognized command line option "-std=3Dc++11" > ... >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-12, at 01:24 PM, Warner Losh wrote: >=20 > Sorry to top post, but try adding WITH_CLANG=3Dt >=20 > Warner >=20 >> On Mar 13, 2015, at 4:18 AM, Mark Millard = wrote: >>=20 >> Basic context: >>=20 >> $ freebsd-version -ku; uname -a >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon = Mar 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc >> $ svnlite info >> Path: . >> Working Copy Root Path: /usr/ports >> URL: https://svn0.us-west.freebsd.org/ports/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 380683 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: demon >> Last Changed Rev: 380683 >> Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >>=20 >> I bootstrapped into 11.0-CURRENT from 10.1-STABLE but misunderstood = UPDATING for the combination of starting from 10.1 on powerpc/powerpc64 = and ended up without clang for both powerpc and powerpc64 before I = figure that out. >>=20 >> While powerpc64-gcc (and so powerpc64-xtoolchain-gcc) fails to build = when portmaster'd on powerpc64 it does build on powerpc. >>=20 >> So I portmaster'd powerpc64-xtoolchain-gcc in the powerpc (non-64) = 11.0-CURRENT context to attempt a "cross" compile back to powerpc... >>=20 >>=20 >>=20 >> The problem: >> (Or is the below attempt a form of abuse of = powerpc64-xtoolchain-gcc?) >> (Remember: no clang exists beforehand.) >>=20 >> For... >>=20 >> make CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain KERNCONF=3DGENERICvtsc = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>=20 >> or >>=20 >> make CROSS_TOOLCHAIN=3Dpowerpc64-gcc buildworld buildkernel = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>=20 >> Either way the result fails to complete by attempting to use = clang-tblgen when it does not exist (yet?): >>=20 >>> ... >>> -------------------------------------------------------------- >>>>>> stage 1.2: bootstrap tools >>> -------------------------------------------------------------- >>> ... >>> =3D=3D=3D> lib/clang/libllvmx86instprinter (buildincludes) >>> =3D=3D=3D> lib/clang/libllvmx86utils (buildincludes) >>> =3D=3D=3D> lib/clang/include (buildincludes) >>> clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h = /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang= /Basic/arm_neon.td >>> make[6]: exec(clang-tblgen) failed (No such file or directory) >>> *** Error code 1 >>>=20 >>> Stop. >>> make[6]: stopped in /usr/src/lib/clang/include >>> *** Error code 1 >>>=20 >>> Stop. >>> make[5]: stopped in /usr/src/lib/clang >>> *** Error code 1 >>>=20 >>> Stop. >>> make[4]: stopped in /usr/src/lib >>> *** Error code 1 >>>=20 >>> Stop. >>> make[3]: stopped in /usr/src/lib >>> *** Error code 1 >>>=20 >>> Stop. >>> make[2]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/src >>=20 >>=20 >>=20 >> Even if overall this style of bootstrap should not work it seems odd = to me that clang-tblgen use was attempted before it was built. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-toolchain@FreeBSD.ORG Thu Mar 12 22:44:52 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56291A7 for ; Thu, 12 Mar 2015 22:44: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 F173C796 for ; Thu, 12 Mar 2015 22:44:51 +0000 (UTC) Received: (qmail 4690 invoked from network); 12 Mar 2015 22:44:50 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 12 Mar 2015 22:44:50 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 18:44:50 -0400 (EDT) Received: (qmail 11732 invoked from network); 12 Mar 2015 22:44:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Mar 2015 22:44: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 E547E1C4052; Thu, 12 Mar 2015 15:44:44 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Trying to bootstrap libc++ from 11.0-CURRENT with clang 3.4.1 still around from 10.1-STABLE: ld unable to build shared library libcxxrt.so.1 Message-Id: <02BBD42E-3326-4DCC-9A2E-243B680B4815@dsl-only.net> Date: Thu, 12 Mar 2015 15:44:48 -0700 To: FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 22:44:52 -0000 Basic context (more listed at the end of the message): # freebsd-version -ku; uname -a 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG3C0 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 The above powerpc (non-64) 11.0-CURRENT was bootstrapped from = 10.1-STABLE without doing "make delete-old" and the like. So there is a = clang 3.4.1 still in place but without libc++. No port-based compilers = installed, not even powerpc64-xtoolchain-gcc. (In my other copies of the 11.0-CURRENT bootstrap I had run delete-old = --before realizing the lack of a newer clang. I finally realized I had = one powerpc (non-64) snapshot from before "delete-old". So this note is = largely independent of the other notes I've sent in about when clang is = not available and trying to use powerpc64-xtoolchain-gcc to bootstrap = having clang.) The problem... In trying to bootstrap libc++ for clang into 11.0-CURRENT when it has = clang 3.4.1 from the 10.1-STABLE I started by trying to build libcxxrt = (which libc++ requires). So from /usr/src/lib/libcxxrt I tried: "make = clean && make". The result was... ... building shared library libcxxrt.so.1 /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. clang: error: linker command failed with exit code 1 (use -v to see = invocation) *** Error code 1 More context: # more /etc/src.conf CPP=3Dclang-cpp CC=3Dclang CXX=3Dclang++ #CFLAGS+=3D-DELF_VERBOSE #WITH_DEBUG_FILES=3D #WITHOUT_CLANG =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 13 03:44:09 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E98EE7B7 for ; Fri, 13 Mar 2015 03:44: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 9D3DCF6F for ; Fri, 13 Mar 2015 03:44:09 +0000 (UTC) Received: (qmail 6730 invoked from network); 13 Mar 2015 03:44:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Mar 2015 03:44:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Thu, 12 Mar 2015 23:44:02 -0400 (EDT) Received: (qmail 16958 invoked from network); 13 Mar 2015 03:44:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Mar 2015 03:44:02 -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 5EA341C4052; Thu, 12 Mar 2015 20:43:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc/powerpc64 11.0-CURRENT not building clang by default: src.opt.mk not equivalent to 10.1-STABLE bsd.own.mk on the issue From: Mark Millard In-Reply-To: <7A17FBA1-9499-4862-83DF-1C4010D96003@dsl-only.net> Date: Thu, 12 Mar 2015 20:43:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7E317915-DBBE-4BCF-B6DD-45F3F723B9AC@dsl-only.net> References: <7A17FBA1-9499-4862-83DF-1C4010D96003@dsl-only.net> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 03:44:10 -0000 Nathan W. wrote: > This is not the right one. That is related to clang 3.4. The issue is=20= > that clang 3.5+ require a C++11 compiler to build. ... The text that I quoted is from the 11.0-CURRENT UPDATING entry that = starts with the non-FreeBSD-variant-specific 3.5.0 background = information below. May be I originally should not have only extracted = the material I thought fit best for being instructions for powerpc64 = 10.x: i.e., I should have given more context. For future readers, quoting more UPDATING context this time... > 20141231: > Clang, llvm and lldb have been upgraded to 3.5.0 release. >=20 > As of this release, a prerequisite for building clang, llvm = and lldb is > a C++11 capable compiler and C++11 standard library. This = means that to > be able to successfully build the cross-tools stage of = buildworld, with > clang as the bootstrap compiler, your system compiler or cross = compiler > should either be clang 3.3 or later, or gcc 4.8 or later, and = your > system C++ library should be libc++, or libdstdc++ from gcc = 4.8 or > later. The later FreeBSD-variants-specific material makes for a complicated to = read entry for powerpc/powerpc64 10.x. Why? Paragraph by paragraph for = the next couple of paragraphs that follow the above... > On any standard FreeBSD 10.x or 11.x installation, where clang = and > libc++ are on by default (that is, on x86 or arm), this should = work out > of the box. "where clang and libc++ are on by default": the libc++ part excludes = powerpc/powerpc64 10.x. The 3.4.1 status for clang is not sufficient = here, despite being after 3.3. > On 9.x installations where clang is enabled by default, e.g. = on x86 and > powerpc, libc++ will not be enabled by default, so libc++ = should be > built (with clang) and installed first. If both clang and = libc++ are > missing, build clang first, then use it to build libc++. The "9.x" wording above makes no mention of 10.x but powerpc/powerpc64 = 10.x also has clang without having libc++ enabled by default. (Nor the = libcxxrt that libc++ requires.) The instructions from here seem to be = the ones that would apply (and likely do for powerpc64 --but not for = powerpc as stands, see later). After that is 8.x, Sparc64, and mips notes that are not a match to the = powerpc/powerpc64 10.x context --and embedded system notes about cross = builds: > On 8.x and earlier installations, upgrade to 9.x first, and = then follow > the instructions for 9.x above. >=20 > Sparc64 and mips users are unaffected, as they still use gcc = 4.2.1 by > default, and do not build clang. >=20 > Many embedded systems are resource constrained, and will not = be able to > build clang in a reasonable time, or in some cases at all. In = those > cases, cross building bootable systems on amd64 is a = workaround. Taken literally no paragraph explicitly covers powerpc/powerpc64 10.x = contexts for how to bootstrap to have clang present in 11.0-CURRENT. By content the one starting with "On 9.x" is the closest match for = powerpc/powerpc64 10.x. My variant text with []'s might better have been: On 9.x installations where clang is enabled by default, e.g. on = x86 and powerpc [10.x too], libc++ will not be enabled by default, so = libc++ should be built (with clang) and installed first. If both clang and = libc++ are missing, build clang first, then use it to build libc++. That would avoid odd implications for the combination x86 and 10.x by = being explicitly localized to powerpc for the 10.x part. But for powerpc (on-64) 10.1-STABLE even that adjustment would be = wrong/incomplete... powerpc 10.1-STABLE (3.4.1 clang present) does not build libcxxrt: > ... > building shared library libcxxrt.so.1 > /usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. > clang: error: linker command failed with exit code 1 (use -v to see = invocation) > *** Error code 1 That in turn means libc++'s build fails from the missing libcxxrt file = that libc++'s build uses in its linking step. That would make it rather hard to follow the instructions. powerpc64 10.1-STABLE had no such problems building and installing those = two libraries. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 10:01 AM, Mark Millard = wrote: Well there is an entry but when I read it I did not find it clear about = the 10.x status. I think the implication is that the 9.x paragraph also applies to 10.x: On 9.x [and 10.x] installations where clang is enabled by = default, e.g. on x86 and powerpc, libc++ will not be enabled by default, so libc++ should = be built (with clang) and installed first. If both clang and libc++ = are missing, build clang first, then use it to build libc++. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@FreeBSD.ORG Fri Mar 13 23:04:33 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67AF8CC0 for ; Fri, 13 Mar 2015 23:04:33 +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 1A61362D for ; Fri, 13 Mar 2015 23:04:32 +0000 (UTC) Received: (qmail 6761 invoked from network); 13 Mar 2015 23:04:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 13 Mar 2015 23:04:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Fri, 13 Mar 2015 19:04:31 -0400 (EDT) Received: (qmail 11483 invoked from network); 13 Mar 2015 23:04:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Mar 2015 23:04:30 -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 3AF491C4052; Fri, 13 Mar 2015 16:04:25 -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: Fri, 13 Mar 2015 16:04:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <81E69CED-2977-4146-A1DA-B199FDAFE146@dsl-only.net> <20150130005619.GA11558@ivaldir.etoilebsd.net> <89F97E94-AB9F-46C0-9AA2-C4D0680D64E7@dsl-only.net> <60F1C8B5-8621-452B-A6A3-DEE4B48B848D@dsl-only.net> <357555BE-7F87-4B25-95BE-43DD33CD8FE2@dsl-only.net> To: Warner Losh X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 23:04:33 -0000 Overall powerpc64-xtoolchain-gcc does not include its own libc++ for = powerpc64-gcc. Overall, then, an as-is powerpc64-xtoolchain-gcc based powerpc/powerpc64 = build would need to be WITHOUT_CLANG=3D as far as I can tell. = (buildworld/buildkernel but excluding building the clang-based tool = chain.) Trying WITHOUT_CLANG=3D (in /etc/src.conf ) got further but failed with: --- bt_split.So ---^M /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem = /usr/obj/usr/srcC/tmp/usr/include -L/usr/obj/usr/srcC/tmp/usr/lib -fpic = -DPIC -O2 -pipe -I/usr/srcC/lib/libc/include -I/usr/srcC/lib/libc/. ./../include -I/usr/srcC/lib/libc/powerpc -DNLS -D__DBINTERFACE_PRIVATE = -I/usr/srcC/lib/libc/../../contrib/gdtoa = -I/usr/srcC/lib/libc/../../contrib/libc-vis -DINET6 = -I/usr/obj/usr/srcC/lib/libc -I/us r/srcC/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE = -I/usr/srcC/lib/libc/../libmd = -I/usr/srcC/lib/libc/../../contrib/jemalloc/include -DMALLOC_PRODUCTION = -I/usr/srcC/lib/libc/../../contrib/tzcode/st dtime -I/usr/srcC/lib/libc/stdtime -I/usr/srcC/lib/libc/locale = -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/srcC/lib/libc/rpc -DYP = -DNS_CACHING -DSYMBOL_VERSIONING -DSYSCALL_COMPAT -std=3Dgnu99 -fstack- protector -Wsystem-headers -Werror -Wall -Wno-format-y2k = -Wno-uninitialized -Wno-pointer-sign -c = /usr/srcC/lib/libc/db/btree/bt_split.c -o bt_split.So^M ... --- bt_split.So ---^M /usr/srcC/lib/libc/db/btree/bt_split.c: In function '__bt_split':^M /usr/srcC/lib/libc/db/btree/bt_split.c:240:8: error: dereferencing = type-punned pointer will break strict-aliasing rules = [-Werror=3Dstrict-aliasing]^M bt_preserve(t, *(pgno_t *)bl->bytes) =3D=3D RET_ERROR)^M ^^M /usr/srcC/lib/libc/db/btree/bt_split.c: In function 'bt_broot':^M /usr/srcC/lib/libc/db/btree/bt_split.c:548:7: error: dereferencing = type-punned pointer will break strict-aliasing rules = [-Werror=3Dstrict-aliasing]^M bt_preserve(t, *(pgno_t *)bl->bytes) =3D=3D RET_ERROR)^M ^^M ... --- bt_split.So ---^M cc1: all warnings being treated as errors^M *** [bt_split.So] Error code 1^M ^M There may need to be more tailoring someplace before the = powerpc64-xtoolchain-gcc based builds can complete. Is it known what tailoring is needed? Also, as is probably expected, my use of TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc did no good for targeting powerpc instead of = powerpc64: it produces "ELF 64-bit ..." for what it does compile. powerpc64-xtoolchain-gcc (really powerpc64-gcc) will not build on = powerpc64: no self hosting as stands. There is no powerpc-xtoolchain-gcc = (yet?). So it looks like once I know the tailoring required further experiments = will only be building powerpc64 builds from powerpc builds. Another powerpc64-xtoolchain-gcc point that I noticed was that = ${XSTRING} would not find the strings file to execute. Details follow... (I use /usr/srcC/ for 11C's /usr/src/ .) /usr/local/powerpc64-freebsd/bin/ is missing strings but = /usr/srcC/Makefile.inc1 expects it to be there based on = CROSS_BUNUTILS_PREFIX pointing there: # more /usr/local/share/toolchains/powerpc64-gcc.mk=20 XCC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc XCXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ XCPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc # ls -FPal /usr/local/powerpc64-freebsd/bin/ total 11400 drwxr-xr-x 2 root wheel 512 Mar 13 12:55 ./ drwxr-xr-x 4 root wheel 512 Mar 13 12:55 ../ -r-xr-xr-x 2 root wheel 989796 Mar 13 12:55 ar* -r-xr-xr-x 2 root wheel 1394156 Mar 13 12:55 as* -r-xr-xr-x 4 root wheel 1593868 Mar 13 12:55 ld* -r-xr-xr-x 4 root wheel 1593868 Mar 13 12:55 ld.bfd* -r-xr-xr-x 2 root wheel 974520 Mar 13 12:55 nm* -r-xr-xr-x 2 root wheel 1139108 Mar 13 12:55 objcopy* -r-xr-xr-x 2 root wheel 1436356 Mar 13 12:55 objdump* -r-xr-xr-x 2 root wheel 989800 Mar 13 12:55 ranlib* lrwxr-xr-x 1 root wheel 32 Mar 13 12:55 size@ -> = ../../bin/powerpc64-freebsd-size -r-xr-xr-x 2 root wheel 1139112 Mar 13 12:55 strip* So no "strings" but... /usr/srcC/Makefile.inc1 prepends ${CROSS_BINUTILS_PREFIX} to ${STRINGS} = to create XSTRINGS: XBINUTILS=3D AS AR LD NM OBJCOPY OBJDUMP RANLIB SIZE STRINGS .for BINUTIL in ${XBINUTILS} .if defined(CROSS_BINUTILS_PREFIX) X${BINUTIL}?=3D ${CROSS_BINUTILS_PREFIX}${${BINUTIL}} .else X${BINUTIL}?=3D ${${BINUTIL}} .endif .endfor So if a build later uses ${XSTRINGS} it will not find it in the file = system for powerpc64-xtoolchain-gcc. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 03:13 PM, Mark Millard = wrote: Warner wrote: > Is cc1plus the g++ compiler that is installed on your bootstrapped = system, or is it the one that the powerpc64-gcc toolchain built? cc1plus = -v will help determine that. You may have to find it on your system = (there=E2=80=99s likely 2) and pass it the -std=3Dc++11 option to see = which of them fail. We may have a leak / problem with mkdep that your = unique setup is revealing. The below details indicate that gcc 4.2.1's /usr/libexec/cc1plus was in = use when the message about -std=3Dc++11 being unrecognized was generated = for "make WITH_CLANG=3Dt CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc". Details... # which cc1plus # So no cc1plus is in my default path: it is being found another way. Ingoring the /usr/src/... and /usr/obj/... paths that have a cc1plus... $ find / -name cc1plus -print /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus ... /usr/libexec/cc1plus ... No others. $ ls -FPal = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 14582156 Mar 12 10:25 = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1* -r-xr-xr-x 1 root wheel 15771164 Mar 12 10:25 = /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus* $ ls -FPal /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 6541860 Mar 10 23:21 /usr/libexec/cc1* -r-xr-xr-x 1 root wheel 7115952 Mar 10 23:21 /usr/libexec/cc1plus* $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus -v ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1/powerpc64-portbld-freebsd11.0" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include/c++/4.9.1/backward" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/sys-include" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/../../../../powerp= c64-portbld-freebsd11.0/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/4.9.1/include-fixed End of search list. ^C $ /usr/libexec/cc1plus -v #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/backward /usr/include/gcc/4.2 /usr/include End of search list. ^C $ /usr/local/libexec/gcc/powerpc64-portbld-freebsd11.0/4.9.1/cc1plus = -std=3Dc++11 ^C $ /usr/libexec/cc1plus -std=3Dc++11 cc1plus: error: unrecognized command line option "-std=3Dc++11" ^C =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-12, at 02:33 PM, Warner Losh wrote: Thanks Mark. :( Is cc1plus the g++ compiler that is installed on your bootstrapped = system, or is it the one that the powerpc64-gcc toolchain built? cc1plus = -v will help determine that. You may have to find it on your system = (there=E2=80=99s likely 2) and pass it the -std=3Dc++11 option to see = which of them fail. We may have a leak / problem with mkdep that your = unique setup is revealing. Warner > On Mar 13, 2015, at 5:42 AM, Mark Millard wrote: >=20 > Warner L. wrote about my attempt to use = rpc64-xtoolchain-gcc/powerpc64-gcc in a powerpc (non-64) context that = has no clang built: >=20 >> Trying WITH_CLANG=3Dt ... >=20 > So I did... >=20 > make WITH_CLANG=3Dt CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >=20 > This results in a different failure (cc1plus not understanding the = -std=3Dc++11 option that it ends up being given): >=20 > -------------------------------------------------------------- >>>> stage 1.2: bootstrap tools > -------------------------------------------------------------- > ... > mkdep -f .depend -a = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/incl= ude = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support = -I. = -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/= include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc-unknown-freebsd11.0\" = -DDEFAULT_SYSROOT=3D\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include = -std=3Dc++11 = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp > ... ... = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/raw_os= tream.cpp > cc1plus: error: unrecognized command line option "-std=3Dc++11" > cc1plus: error: unrecognized command line option "-std=3Dc++11" > cc1plus: error: unrecognized command line option "-std=3Dc++11" > ... >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-12, at 01:24 PM, Warner Losh wrote: >=20 > Sorry to top post, but try adding WITH_CLANG=3Dt >=20 > Warner >=20 >> On Mar 13, 2015, at 4:18 AM, Mark Millard = wrote: >>=20 >> Basic context: >>=20 >> $ freebsd-version -ku; uname -a >> 11.0-CURRENT >> 11.0-CURRENT >> FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon = Mar 9 22:24:27 PDT 2015 = root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG powerpc >> $ svnlite info >> Path: . >> Working Copy Root Path: /usr/ports >> URL: https://svn0.us-west.freebsd.org/ports/head >> Relative URL: ^/head >> Repository Root: https://svn0.us-west.freebsd.org/ports >> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 >> Revision: 380683 >> Node Kind: directory >> Schedule: normal >> Last Changed Author: demon >> Last Changed Rev: 380683 >> Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >>=20 >> I bootstrapped into 11.0-CURRENT from 10.1-STABLE but misunderstood = UPDATING for the combination of starting from 10.1 on powerpc/powerpc64 = and ended up without clang for both powerpc and powerpc64 before I = figure that out. >>=20 >> While powerpc64-gcc (and so powerpc64-xtoolchain-gcc) fails to build = when portmaster'd on powerpc64 it does build on powerpc. >>=20 >> So I portmaster'd powerpc64-xtoolchain-gcc in the powerpc (non-64) = 11.0-CURRENT context to attempt a "cross" compile back to powerpc... >>=20 >>=20 >>=20 >> The problem: >> (Or is the below attempt a form of abuse of = powerpc64-xtoolchain-gcc?) >> (Remember: no clang exists beforehand.) >>=20 >> For... >>=20 >> make CROSS_TOOLCHAIN=3Dpowerpc64-gcc toolchain KERNCONF=3DGENERICvtsc = TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>=20 >> or >>=20 >> make CROSS_TOOLCHAIN=3Dpowerpc64-gcc buildworld buildkernel = KERNCONF=3DGENERICvtsc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc >>=20 >> Either way the result fails to complete by attempting to use = clang-tblgen when it does not exist (yet?): >>=20 >>> ... >>> -------------------------------------------------------------- >>>>>> stage 1.2: bootstrap tools >>> -------------------------------------------------------------- >>> ... >>> =3D=3D=3D> lib/clang/libllvmx86instprinter (buildincludes) >>> =3D=3D=3D> lib/clang/libllvmx86utils (buildincludes) >>> =3D=3D=3D> lib/clang/include (buildincludes) >>> clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h = /usr/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang= /Basic/arm_neon.td >>> make[6]: exec(clang-tblgen) failed (No such file or directory) >>> *** Error code 1 >>>=20 >>> Stop. >>> make[6]: stopped in /usr/src/lib/clang/include >>> *** Error code 1 >>>=20 >>> Stop. >>> make[5]: stopped in /usr/src/lib/clang >>> *** Error code 1 >>>=20 >>> Stop. >>> make[4]: stopped in /usr/src/lib >>> *** Error code 1 >>>=20 >>> Stop. >>> make[3]: stopped in /usr/src/lib >>> *** Error code 1 >>>=20 >>> Stop. >>> make[2]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make[1]: stopped in /usr/src >>> *** Error code 1 >>>=20 >>> Stop. >>> make: stopped in /usr/src >>=20 >>=20 >>=20 >> Even if overall this style of bootstrap should not work it seems odd = to me that clang-tblgen use was attempted before it was built. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 >=20 From owner-freebsd-toolchain@FreeBSD.ORG Sat Mar 14 05:43:11 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9440A8FB for ; Sat, 14 Mar 2015 05:43: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 4CECAFC8 for ; Sat, 14 Mar 2015 05:43:11 +0000 (UTC) Received: (qmail 31753 invoked from network); 14 Mar 2015 05:43:03 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Mar 2015 05:43:03 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 14 Mar 2015 01:43:03 -0400 (EDT) Received: (qmail 27018 invoked from network); 14 Mar 2015 05:43:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Mar 2015 05:43:03 -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 748691C4052; Fri, 13 Mar 2015 22:42:56 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc (non-64) using CROSS_TOOLCHAIN=powerpc64-gcc fails: .TOC.@tocbase notation not recognized Message-Id: <9855CD5C-9086-412F-AD5B-370EAC58D4EC@dsl-only.net> Date: Fri, 13 Mar 2015 22:43:01 -0700 To: FreeBSD PowerPC ML , freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 05:43:11 -0000 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