From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 8 06:22:56 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11FA6531 for ; Sun, 8 Mar 2015 06:22: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 B78C6179 for ; Sun, 8 Mar 2015 06:22:54 +0000 (UTC) Received: (qmail 15765 invoked from network); 8 Mar 2015 06:16:13 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 8 Mar 2015 06:16:13 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 01:16:13 -0500 (EST) Received: (qmail 22529 invoked from network); 8 Mar 2015 06:16:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Mar 2015 06:16:06 -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 EE4F41C43A2; Sat, 7 Mar 2015 22:15:58 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 context, sysutils/polkit fails to build: broken pipe during /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py Message-Id: Date: Sat, 7 Mar 2015 22:16:03 -0800 To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 06:22:56 -0000 powerpc64 context (more details are listed later): $ 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 Ports Revision 380683 via svnlite update. I've been using portmaster. The problem (which I've not figured out yet)... x11/xorg, x11-drivers/xf86-video-ati-ums, x11-drivers/xf86-video-scfb, = and x11-wm/xfce4 are all blocked from building by sysutils/polkit = failing to build because of a broken pipe with a subprocess... ... gmake all-am gmake[6]: Entering directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' CC libpolkit_gobject_1_la-polkitenumtypes.lo CC libpolkit_gobject_1_la-polkitactiondescription.lo CC libpolkit_gobject_1_la-polkitauthorityfeatures.lo CC libpolkit_gobject_1_la-polkitdetails.lo CC libpolkit_gobject_1_la-polkitauthority.lo CC libpolkit_gobject_1_la-polkiterror.lo CC libpolkit_gobject_1_la-polkitsubject.lo CC libpolkit_gobject_1_la-polkitunixprocess.lo CC libpolkit_gobject_1_la-polkitsystembusname.lo CC libpolkit_gobject_1_la-polkitidentity.lo CC libpolkit_gobject_1_la-polkitunixuser.lo CC libpolkit_gobject_1_la-polkitunixgroup.lo CC libpolkit_gobject_1_la-polkitunixnetgroup.lo CC libpolkit_gobject_1_la-polkitauthorizationresult.lo CC libpolkit_gobject_1_la-polkitcheckauthorizationflags.lo CC libpolkit_gobject_1_la-polkitimplicitauthorization.lo CC libpolkit_gobject_1_la-polkittemporaryauthorization.lo CC libpolkit_gobject_1_la-polkitpermission.lo CC libpolkit_gobject_1_la-polkitunixsession.lo CCLD libpolkit-gobject-1.la GISCAN Polkit-1.0.gir Traceback (most recent call last): File "/usr/local/bin/g-ir-scanner", line 55, in sys.exit(scanner_main(sys.argv)) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 517, in scanner_main ss =3D create_source_scanner(options, args) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 430, in create_source_scanner ss.parse_files(filenames) File = "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line = 256, in parse_files self._parse(headers) File = "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line = 302, in _parse proc.stdin.write('#ifndef %s\n' % (define, )) IOError: [Errno 32] Broken pipe /usr/local/share/gobject-introspection-1.0/Makefile.introspection:153: = recipe for target 'Polkit-1.0.gir' failed gmake[6]: *** [Polkit-1.0.gir] Error 1 gmake[6]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:444: recipe for target 'all' failed gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:326: recipe for target 'all-recursive' failed gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src' Makefile:374: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' Makefile:305: recipe for target 'all' failed gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' *** Error code 1 Stop. make[1]: stopped in /usr/ports/sysutils/polkit *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/polkit =3D=3D=3D>>> make build failed for sysutils/polkit =3D=3D=3D>>> Aborting update =3D=3D=3D>>> You can restart from the point of failure with this command = line: portmaster sysutils/polkit=20 The relevant = /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py code = being... def _parse(self, filenames): if not filenames: return =20 defines =3D ['__GI_SCANNER__'] undefs =3D [] cpp_args =3D os.environ.get('CC', 'cc').split() # support = CC=3D"ccache gcc" if 'cl' in cpp_args: # The Microsoft compiler/preprocessor (cl) does not accept # source input from stdin (the '-' flag), so we need # some help from gcc from MinGW/Cygwin or so. # Note that the generated dumper program is # still built and linked by Visual C++. cpp_args =3D ['gcc'] cpp_args +=3D os.environ.get('CPPFLAGS', '').split() cpp_args +=3D os.environ.get('CFLAGS', '').split() cpp_args +=3D ['-E', '-C', '-I.', '-'] cpp_args +=3D self._cpp_options proc =3D subprocess.Popen(cpp_args, stdin=3Dsubprocess.PIPE, stdout=3Dsubprocess.PIPE) for define in defines: proc.stdin.write('#ifndef %s\n' % (define, )) proc.stdin.write('# define %s\n' % (define, )) proc.stdin.write('#endif\n') ... For my context the overall environment has (but ports might force other = ports as alternatives to): # 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 # which cc /usr/bin/cc # 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. # which clang /usr/bin/clang # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc64-unknown-freebsd10.1 Thread model: posix Other context details: $ 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 =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 $ 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 PowerMac G5 specific change to avoid = intermittent boot problems. 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. 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/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 8 06:56:34 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73E2D8F1 for ; Sun, 8 Mar 2015 06:56:34 +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 29C72614 for ; Sun, 8 Mar 2015 06:56:33 +0000 (UTC) Received: (qmail 10305 invoked from network); 8 Mar 2015 06:56:32 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Mar 2015 06:56:32 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 01:56:32 -0500 (EST) Received: (qmail 13323 invoked from network); 8 Mar 2015 06:56:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Mar 2015 06:56:32 -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 CCA9F1C43A2; Sat, 7 Mar 2015 22:56:24 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc64 10.1-STABLE context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it Message-Id: Date: Sat, 7 Mar 2015 22:56:30 -0800 To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 06:56:34 -0000 powerpc64 context (more details are listed much later): $ 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 Ports Revision 380683 via svnlite update. I've been using portmaster. The problem (which I've not figured out yet)... 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: #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 The specific Makefile code to invoke ctest is... # 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 =20 # Special rule for the target test test/fast: test .PHONY : test/fast which because of ctest's problem leads to... ... 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"install -o root -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 make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 1 error make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 [: xTry: unexpected operator *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/png *** Error code 1 Stop. make: stopped in /usr/ports/graphics/png Even just ctest as a command gets the vector::reserve size problem from = the large magic number: $ ctest ********************************* No test configuration file found! ********************************* terminate called after throwing an instance of 'std::length_error' what(): vector::reserve Abort trap (core dumped) [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.] For my context the overall environment has (but ports might force other = ports as alternatives to): # 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 # which cc /usr/bin/cc # 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. # which clang /usr/bin/clang # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc64-unknown-freebsd10.1 Thread model: posix Other context details: $ 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 $ 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 PowerMac G5 specific change to avoid = intermittent boot problems. 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. 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/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 8 10:22:58 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4DB2BD77 for ; Sun, 8 Mar 2015 10:22:58 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC71AB3A for ; Sun, 8 Mar 2015 10:22:56 +0000 (UTC) Received: (qmail 20936 invoked from network); 8 Mar 2015 10:22:55 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Mar 2015 10:22:55 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 06:22:55 -0400 (EDT) Received: (qmail 28271 invoked from network); 8 Mar 2015 10:22:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 8 Mar 2015 10:22:54 -0000 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 1D3481C43A2 for ; Sun, 8 Mar 2015 03:22:53 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 10.1-STABLE kern.vty=vt crashes PowerMac G5 extremely early in boot for 2560x1440 display... Message-Id: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> Date: Sun, 8 Mar 2015 03:22:52 -0700 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 10:22:58 -0000 Basic context: $ 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 The crash details (X11 is not part of the context, just console use): I tried using a 2560x1440 display with a PowerMac G5 but forgot to = switch from kern.vty=3Dvt to kern.vty=3Dsc in /boot/loader.conf first. But the result was new since the last time I'd done such a thing (long = ago)... It crashed so early that it returned to Apple's OpenFirmware. That allowed me to use .registers in OpenFirmware to find where it had = crashed at. It turned out that the Interrupt Vector was 0x700 and SRR0 was 0x380. = (Openfirmare does not put an exception handler at 0x380 (leaving zeros) = so a 0x380 exception handler's attempted use leads to a double fault = when OpenFirmware's handlers are all that are in place, the 2nd of the = pair going to the 0x700 exception handler.) Luckily LR is preserved in this sequence and it ended up pointing to: vtbuf_init_early+0x78 (0x40787c was the address for the build) and that was the instruction after a bl to .vtbuf_fill. This was fully repeatable. As conformation of the size dependency: Switching to a smaller display = booted fine (again fully repeatable). I'll note that kern.vty=3Dsc handles the 2560x1440 display fine for that = same PowerMac G5. sc uses most but not all of the width and it uses all = of the height. 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 PowerMac G5 specific change to avoid = intermittent boot problems. 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. 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/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. # 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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 8 16:49:33 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8E04E16; Sun, 8 Mar 2015 16:49:33 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 8C25E276; Sun, 8 Mar 2015 16:49:33 +0000 (UTC) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t28GnMs3007588 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Mar 2015 09:49:23 -0700 Message-ID: <54FC7D92.3010405@freebsd.org> Date: Sun, 08 Mar 2015 09:49:22 -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: Mark Millard , freebsd-ports@freebsd.org, FreeBSD PowerPC ML Subject: Re: powerpc64 10.1-STABLE context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Sonic-CAuth: UmFuZG9tSVbK0E+jwd3Zn/SJMDljKko7INoP5NuObMFbdZTJFJse+sf9IriLn6fET45q0b0Mv0Sz+lCuRnnjJF2RiqFONk7MXdMTqzBMYus= X-Sonic-ID: C;PIFJErPF5BGmQO8Jj30JFw== M;MPG3ErPF5BGmQO8Jj30JFw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:49:33 -0000 This works fine for me. Are you sure you don't have some weird=20 configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): > > $ 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 > > Ports Revision 380683 via svnlite update. I've been using portmaster. > > > The problem (which I've not figured out yet)... > > When png-1.6.16 has PNGTEST enabled (default and "recommended") it trie= s 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 .= =2E.::reserve (..., __n=3D...) below] when _M_initialize_buckets(..., __n= =3D100) in #9. (Note: 2305843009213693952 =3D=3D 0x2000000000000000.) I h= ave yet to figure out how that magic number is becoming involved. See bel= ow from one of the crash dumps: > > #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/l= ibsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from /usr/lib/libsupc++.s= o.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from /usr/l= ib/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=3D0xffffffffffff= b100, __n=3D100) at hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, __n=3D1= 00, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, __a=3D@0xfff= fffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at hash_= map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, par= ent=3D0x0) at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/S= ource/cmDefinitions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at /usr/obj/po= rtswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefile.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator (this=3D= 0x51c3f480, gg=3D0xffffffffffffc138) at /usr/obj/portswork/usr/ports/deve= l/cmake/work/cmake-3.1.3/Source/cmLocalGenerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator (this= =3D0xffffffffffffc138) at /usr/obj/portswork/usr/ports/devel/cmake/work/c= make-3.1.3/Source/cmGlobalGenerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize (this=3D0xffffffffffffcf5= 0, binary_dir=3D0x51c890f8 "/usr/obj/portswork/usr/ports/graphics/png/wor= k/libpng-1.6.16", command=3D0x0) > at /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Sourc= e/cmCTest.cxx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, args= =3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at /usr/obj/portswor= k/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.cxx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at /usr/ob= j/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 > > The specific Makefile code to invoke ctest is... > > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) --cy= an "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > =20 > # Special rule for the target test > test/fast: test > .PHONY : test/fast > > which because of ctest's problem leads to... > > ... > 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/wo= rk XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work HOM= E=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" XDG_DA= TA_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/portsw= ork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" DONTSTRIP=3Dyes NO_PIE=3D= yes SHELL=3D/bin/sh NO_LINT=3DYES PREFIX=3D/usr/local LOCALBASE=3D/usr/l= ocal LIBDIR=3D"/usr/lib" CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-alia= sing" CPP=3D"cpp" CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXX= FLAGS=3D"-pipe -g -fno-strict-aliasing " MANPREFIX=3D"/usr/local" BSD_IN= STALL_PROGRAM=3D"install -o root -g wheel -m 555" BSD_INSTALL_LIB=3D"i= nstall -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/p= ortswork/usr/ports/graphics/png/work/stage test; then if [ x !=3D xTry t= o set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to = the maintainer. ] ; then echo "=3D=3D=3D> Compilation failed unexpectedl= y."; (echo Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reportin= g 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 > > make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libp= ng-1.6.16 > 1 error > > make[2]: stopped in /usr/obj/portswork/usr/ports/graphics/png/work/libp= ng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 > > Stop. > make: stopped in /usr/ports/graphics/png > > > Even just ctest as a command gets the vector::reserve size problem from= the large magic number: > > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > > > [So far I've only sidestepped having graphic/png run ctest to allow som= e things that depend on graphics/png to not be blocked by this.] > > > > > For my context the overall environment has (but ports might force other= ports as alternatives to): > > # 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 > > # which cc > /usr/bin/cc > > # 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 PURP= OSE. > > # which clang > /usr/bin/clang > > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 2014051= 2 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix > > > > > > Other context details: > > $ 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 > > $ 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 PowerMac G5 specific change to avoi= d intermittent boot problems. > > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get evi= dence if I do end up with another early-boot failure. DDB and GDB are lis= ted in sys/powerpc/conf/GENERIC64vtsc 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 DM= A request size. > > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both v= t and sc. It includes the standard GENERIC64. > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 8 16:52:12 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D6C4132 for ; Sun, 8 Mar 2015 16:52:12 +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 2D50D34C for ; Sun, 8 Mar 2015 16:52:11 +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 t28Gq9fk008930 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 8 Mar 2015 09:52:10 -0700 Message-ID: <54FC7E39.3010602@freebsd.org> Date: Sun, 08 Mar 2015 09:52:09 -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-ppc@freebsd.org Subject: Re: 10.1-STABLE kern.vty=vt crashes PowerMac G5 extremely early in boot for 2560x1440 display... References: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> In-Reply-To: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVZDUdP8JvFAywhYjANhru8nFIY6KgmC7BxQI0TIHVy75XaGo2jvqjJRBGblDv+jvuGL6KcMCqLh7qXFveKZij3eQpfuYJinsww= X-Sonic-ID: C;/nbidbPF5BGD075YxQPdhw== M;TOIjdrPF5BGD075YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:52:12 -0000 Could you please try -CURRENT? vt itself at least works fine there, but I'm not sure anyone has tested it with such a large display on any platform. -Nathan On 03/08/15 03:22, Mark Millard wrote: > Basic context: > > $ 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 > > > The crash details (X11 is not part of the context, just console use): > > I tried using a 2560x1440 display with a PowerMac G5 but forgot to switch from kern.vty=vt to kern.vty=sc in /boot/loader.conf first. > > But the result was new since the last time I'd done such a thing (long ago)... > > It crashed so early that it returned to Apple's OpenFirmware. > > That allowed me to use .registers in OpenFirmware to find where it had crashed at. > > It turned out that the Interrupt Vector was 0x700 and SRR0 was 0x380. (Openfirmare does not put an exception handler at 0x380 (leaving zeros) so a 0x380 exception handler's attempted use leads to a double fault when OpenFirmware's handlers are all that are in place, the 2nd of the pair going to the 0x700 exception handler.) > > Luckily LR is preserved in this sequence and it ended up pointing to: > > vtbuf_init_early+0x78 (0x40787c was the address for the build) > > and that was the instruction after a bl to .vtbuf_fill. > > This was fully repeatable. > > > As conformation of the size dependency: Switching to a smaller display booted fine (again fully repeatable). > > > I'll note that kern.vty=sc handles the 2560x1440 display fine for that same PowerMac G5. sc uses most but not all of the width and it uses all of the height. > > > 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 PowerMac G5 specific change to avoid intermittent boot problems. > > 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. > > 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/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64. > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > MALLOC_PRODUCTION= > > # more /etc/src.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > #CFLAGS+=-DELF_VERBOSE > #WITH_DEBUG_FILES= > #WITHOUT_CLANG > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Sun Mar 8 16:53:11 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10007151; Sun, 8 Mar 2015 16:53:11 +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 E706E34E; Sun, 8 Mar 2015 16:53:10 +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 t28Gr7PN009329 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Mar 2015 09:53:07 -0700 Message-ID: <54FC7E73.4040205@freebsd.org> Date: Sun, 08 Mar 2015 09:53:07 -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: Mark Millard , freebsd-ports@freebsd.org, FreeBSD PowerPC ML Subject: Re: powerpc64 context, sysutils/polkit fails to build: broken pipe during /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYaSoLZHX0ZO4lybtuPGLfiw28PPFjc5VYjQgyLz9tBg7qZzK+vm0kvfUxF2oNUhdQzicKuZx06Es3SpyOVrVc30DMkH5EMJAQ= X-Sonic-ID: C;XsJLmLPF5BG3NL5YxQPdhw== M;SH2ImLPF5BG3NL5YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2015 16:53:11 -0000 This builds without issue for me, both on a G5 system and on a POWER8. -Nathan On 03/07/15 22:16, Mark Millard wrote: > powerpc64 context (more details are listed later): > > $ 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 > > Ports Revision 380683 via svnlite update. I've been using portmaster. > > > The problem (which I've not figured out yet)... > > x11/xorg, x11-drivers/xf86-video-ati-ums, x11-drivers/xf86-video-scfb, and x11-wm/xfce4 are all blocked from building by sysutils/polkit failing to build because of a broken pipe with a subprocess... > > ... > gmake all-am > gmake[6]: Entering directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit' > CC libpolkit_gobject_1_la-polkitenumtypes.lo > CC libpolkit_gobject_1_la-polkitactiondescription.lo > CC libpolkit_gobject_1_la-polkitauthorityfeatures.lo > CC libpolkit_gobject_1_la-polkitdetails.lo > CC libpolkit_gobject_1_la-polkitauthority.lo > CC libpolkit_gobject_1_la-polkiterror.lo > CC libpolkit_gobject_1_la-polkitsubject.lo > CC libpolkit_gobject_1_la-polkitunixprocess.lo > CC libpolkit_gobject_1_la-polkitsystembusname.lo > CC libpolkit_gobject_1_la-polkitidentity.lo > CC libpolkit_gobject_1_la-polkitunixuser.lo > CC libpolkit_gobject_1_la-polkitunixgroup.lo > CC libpolkit_gobject_1_la-polkitunixnetgroup.lo > CC libpolkit_gobject_1_la-polkitauthorizationresult.lo > CC libpolkit_gobject_1_la-polkitcheckauthorizationflags.lo > CC libpolkit_gobject_1_la-polkitimplicitauthorization.lo > CC libpolkit_gobject_1_la-polkittemporaryauthorization.lo > CC libpolkit_gobject_1_la-polkitpermission.lo > CC libpolkit_gobject_1_la-polkitunixsession.lo > CCLD libpolkit-gobject-1.la > GISCAN Polkit-1.0.gir > Traceback (most recent call last): > File "/usr/local/bin/g-ir-scanner", line 55, in > sys.exit(scanner_main(sys.argv)) > File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", line 517, in scanner_main > ss = create_source_scanner(options, args) > File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", line 430, in create_source_scanner > ss.parse_files(filenames) > File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line 256, in parse_files > self._parse(headers) > File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", line 302, in _parse > proc.stdin.write('#ifndef %s\n' % (define, )) > IOError: [Errno 32] Broken pipe > /usr/local/share/gobject-introspection-1.0/Makefile.introspection:153: recipe for target 'Polkit-1.0.gir' failed > gmake[6]: *** [Polkit-1.0.gir] Error 1 > gmake[6]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit' > Makefile:444: recipe for target 'all' failed > gmake[5]: *** [all] Error 2 > gmake[5]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit' > Makefile:326: recipe for target 'all-recursive' failed > gmake[4]: *** [all-recursive] Error 1 > gmake[4]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src' > Makefile:374: recipe for target 'all-recursive' failed > gmake[3]: *** [all-recursive] Error 1 > gmake[3]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' > Makefile:305: recipe for target 'all' failed > gmake[2]: *** [all] Error 2 > gmake[2]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/sysutils/polkit > *** Error code 1 > > Stop. > make: stopped in /usr/ports/sysutils/polkit > > ===>>> make build failed for sysutils/polkit > ===>>> Aborting update > > > ===>>> You can restart from the point of failure with this command line: > portmaster sysutils/polkit > > The relevant /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py code being... > > def _parse(self, filenames): > if not filenames: > return > > defines = ['__GI_SCANNER__'] > undefs = [] > cpp_args = os.environ.get('CC', 'cc').split() # support CC="ccache gcc" > if 'cl' in cpp_args: > # The Microsoft compiler/preprocessor (cl) does not accept > # source input from stdin (the '-' flag), so we need > # some help from gcc from MinGW/Cygwin or so. > # Note that the generated dumper program is > # still built and linked by Visual C++. > cpp_args = ['gcc'] > cpp_args += os.environ.get('CPPFLAGS', '').split() > cpp_args += os.environ.get('CFLAGS', '').split() > cpp_args += ['-E', '-C', '-I.', '-'] > cpp_args += self._cpp_options > > proc = subprocess.Popen(cpp_args, > stdin=subprocess.PIPE, > stdout=subprocess.PIPE) > > for define in defines: > proc.stdin.write('#ifndef %s\n' % (define, )) > proc.stdin.write('# define %s\n' % (define, )) > proc.stdin.write('#endif\n') > ... > > For my context the overall environment has (but ports might force other ports as alternatives to): > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > MALLOC_PRODUCTION= > > # more /etc/src.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > #CFLAGS+=-DELF_VERBOSE > #WITH_DEBUG_FILES= > #WITHOUT_CLANG > > # which cc > /usr/bin/cc > > # 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. > > # which clang > /usr/bin/clang > > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix > > > > > > Other context details: > > $ 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 > =================================================================== > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=--enable-vdpau > .endif > > +.if ${ARCH} == powerpc64 > +CFLAGS+= -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e 's|x86_64|amd64|' \ > ${WRKSRC}/configure > > $ 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 PowerMac G5 specific change to avoid intermittent boot problems. > > 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. > > 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/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64. > > > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 9 01:35:11 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 515D0892 for ; Mon, 9 Mar 2015 01:35: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 02B093E4 for ; Mon, 9 Mar 2015 01:35:10 +0000 (UTC) Received: (qmail 31831 invoked from network); 9 Mar 2015 01:35:08 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Mar 2015 01:35:08 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 08 Mar 2015 21:35:08 -0400 (EDT) Received: (qmail 17845 invoked from network); 9 Mar 2015 01:35:08 -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 01:35:08 -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 67FEF1C405E; Sun, 8 Mar 2015 18:34:59 -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 context; cmake's /usr/local/bin/ctest broken but graphics/png configuration defaults use it From: Mark Millard In-Reply-To: <54FC7D92.3010405@freebsd.org> Date: Sun, 8 Mar 2015 18:35:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54FC7D92.3010405@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 01:35:11 -0000 Thanks for the note. It is useful to know the variation from my context. You were not explicit but because you mention POWER8 I'd guess that you = were reporting based on 11.0-CURRENT. I have not yet established an = 11.0-CURRENT boot-context, although I plan to at some point. powerpc64 vs. powerpc builds give different results... For powerpc64 I decided to "pkg delete '*'", check /usr/local/... and = /var/db/pkg/..., and start a rebuild of all my ports to see what = happens. For powerpc I'm just establishing a boot-SSD context now. The activity for both has gotten past cmake and I get the following = results for ctest on the G5s where the builds are running: powerpc64 build: ctest still messed up with std::length_error from = vector::reserve. powerpc build: ctest works fine. Both are being run on PowerMac G5s. Both are still building more ports. As for potential HW problems and HW configuration problems: I have access to 3 PowerMac G5's and they all behaved the same for each = specific build: PowerMac11,2 (Quad-Core) G5 with 16GBytes ECC RAM PowerMac11,2 (Quad-Core) G5 with 12GBytes RAM PowerMac7,2 (Dual-processor) G5 with 8GBytes RAM All of these have only one board installed: the video board. Normally = there is only one "disk" present when in use: a boot SSD on ada0. The only common HW element in my testing G5 behavior is my moving my = boot SSD that I'm testing. Non-SSD hardware is rarely the issue with anything that I report unless = I'm reporting differences in behavior between the PowerMacs that I have = access to for the type of build involved: I have a compare/contrast = environment available for my testing and I use it. [I have access to multiple G4 PowerMacs of various vintages and a G3 = PowerMac as well, similarly minimal configurations. But I'm only now = re-establishing having a FreeBSD context for these after mostly = abandoning them for much of the 9-10 months while I was investigating = the frequent PowerMac G5 early-boot-crash problems as my primary FreeBSD = activity.] The powerpc64 PowerMac G5 boot-SSD content that I use for 10.1-STABLE = and 10.1-RELENG could certainly be suspect in some way. :) I mostly use = 10.1-STABLE, currently: $ freebsd-version -ku; uname -a 10.1-STABLE 10.1-STABLE FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar 6 = 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc As for other configuration points: See my original note for more details on the difference from the = official world/kernel materials. There is also /boot/loader.conf picking = out a kernel (I use INSTKERNNAME=3D with non-default names mostly) and = picking out vt vs. sc, /etc/fstab, /etc/rc.conf (hostname, ifconfig_ = for ethernet, ntpd_, dumpdev, hald_enable, dbus_enable), = /etc/sysctl.conf for /var/crash/ related items. Counting the original = note's list of differences: Not much else is different from the = default/official materials. For ports configurations: Before I had suspended trying to track the = ports status I historically had used almost every default selection, = something like 2 to 6 non-default selections. (I keep a snapshot of = /var/db/ports/... as a reference/reminder.) I've got the same policy for = trying to re-establish the ports now that I can reliably boot the G5s. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn = wrote: This works fine for me. Are you sure you don't have some weird = configuration or hardware problem? -Nathan On 03/07/15 22:56, Mark Millard wrote: > powerpc64 context (more details are listed much later): >=20 > $ freebsd-version -ku; uname -a > 10.1-STABLE > 10.1-STABLE > FreeBSD FBSDG5S0 10.1-STABLE FreeBSD 10.1-STABLE #0 r279507M: Fri Mar = 6 23:08:59 PST 2015 root@FBSDG5S0:/usr/obj/usr/src/sys/GENERIC64vtsc = powerpc >=20 > Ports Revision 380683 via svnlite update. I've been using portmaster. >=20 >=20 > The problem (which I've not figured out yet)... >=20 > When png-1.6.16 has PNGTEST enabled (default and "recommended") it = tries to use cmake's /usr/local/bin/ctest. But in my context ctest is = broken, trying to reserve 2305843009213693952 Hashtable_node<...>*'s = [see #8's ...::reserve (..., __n=3D...) below] when = _M_initialize_buckets(..., __n=3D100) in #9. (Note: 2305843009213693952 = =3D=3D 0x2000000000000000.) I have yet to figure out how that magic = number is becoming involved. See below from one of the crash dumps: >=20 > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > [New Thread 51c06400 (LWP 100091/ctest)] > (gdb) bt > #0 0x0000000050d17298 in .__sys_thr_kill () from /lib/libc.so.7 > #1 0x0000000050d171ac in .__raise () from /lib/libc.so.7 > #2 0x0000000050d15788 in .abort () from /lib/libc.so.7 > #3 0x00000000514c9ae0 in = ._ZN9__gnu_cxx27__verbose_terminate_handlerEv () from = /usr/lib/libsupc++.so.1 > #4 0x00000000514cf1d8 in ._ZSt14set_unexpectedPFvvE () from = /usr/lib/libsupc++.so.1 > #5 0x00000000514cf230 in ._ZSt9terminatev () from = /usr/lib/libsupc++.so.1 > #6 0x00000000514cf0dc in .__cxa_throw () from /usr/lib/libsupc++.so.1 > #7 0x0000000050ab4e54 in ._ZSt20__throw_length_errorPKc () from = /usr/lib/libstdc++.so.6 > #8 0x000000001024659c in = std::vector >*, = std::allocator >*> >::reserve (this=3D0xffffffffffffb108, = __n=3D2305843009213693952) at vector.tcc:72 > #9 0x00000000104749bc in cmsys::hashtable, std::string, cmsys::hash, = cmsys::hash_select1st, = std::equal_to, std::allocator = >::_M_initialize_buckets (this=3D0xffffffffffffb100, __n=3D100) at = hashtable.hxx:797 > #10 0x0000000010474ae4 in hashtable (this=3D0xffffffffffffb100, = __n=3D100, __hf=3D@0xffffffffffffaeb2, __eql=3D@0xffffffffffffaeb1, = __a=3D@0xffffffffffffaeb0) at hashtable.hxx:545 > #11 0x0000000010474bb8 in hash_map (this=3D0xffffffffffffb100) at = hash_map.hxx:113 > #12 0x0000000010472ba4 in cmDefinitions (this=3D0xffffffffffffb0f8, = parent=3D0x0) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmDefinit= ions.cxx:19 > #13 0x000000001020dc40 in cmMakefile (this=3D0x51cb1800) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmMakefil= e.cxx:56 > #14 0x00000000101efb0c in cmLocalGenerator::SetGlobalGenerator = (this=3D0x51c3f480, gg=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmLocalGe= nerator.cxx:244 > #15 0x00000000101874b0 in cmGlobalGenerator::CreateLocalGenerator = (this=3D0xffffffffffffc138) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmGlobalG= enerator.cxx:1906 > #16 0x00000000100224dc in cmCTest::Initialize = (this=3D0xffffffffffffcf50, binary_dir=3D0x51c890f8 = "/usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16", = command=3D0x0) > at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:511 > #17 0x000000001002c704 in cmCTest::Run (this=3D0xffffffffffffcf50, = args=3D@0xffffffffffffcb80, output=3D0xffffffffffffcb98) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/cmCTest.c= xx:2474 > #18 0x0000000010010c10 in main (argc=3D2, argv=3D0x51c1a040) at = /usr/obj/portswork/usr/ports/devel/cmake/work/cmake-3.1.3/Source/ctest.cxx= :189 > #19 0x000000001000fc9c in ._start () > #20 0x000000005074c8a0 in .text () from /libexec/ld-elf.so.1 >=20 > The specific Makefile code to invoke ctest is... >=20 > # Special rule for the target test > test: > @$(CMAKE_COMMAND) -E cmake_echo_color --switch=3D$(COLOR) = --cyan "Running tests..." > /usr/local/bin/ctest --force-new-ctest-process $(ARGS) > .PHONY : test > # Special rule for the target test > test/fast: test > .PHONY : test/fast >=20 > which because of ctest's problem leads to... >=20 > ... > Linking C executable pngvalid > [100%] Built target pngvalid > (cd /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16; if ! = /usr/bin/env = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = XDG_DATA_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = XDG_CONFIG_HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work = HOME=3D/usr/obj/portswork/usr/ports/graphics/png/work TMPDIR=3D"/tmp" = DONTSTRIP=3Dyes NO_PIE=3Dyes SHELL=3D/bin/sh NO_LINT=3DYES = PREFIX=3D/usr/local LOCALBASE=3D/usr/local LIBDIR=3D"/usr/lib" = CC=3D"cc" CFLAGS=3D"-pipe -g -fno-strict-aliasing" CPP=3D"cpp" = CPPFLAGS=3D"" LDFLAGS=3D"" LIBS=3D"" CXX=3D"c++" CXXFLAGS=3D"-pipe -g = -fno-strict-aliasing " MANPREFIX=3D"/usr/local" = BSD_INSTALL_PROGRAM=3D"install -o root -g wheel -m 555" = BSD_INSTALL_LIB=3D"install -o root -g wheel -m 444" = BSD_INSTALL_SCRIPT=3D"install -o root -g wheel -m 555" = BSD_INSTALL_DATA=3D"install -o root -g wheel -m 0644" = BSD_INSTALL_MAN=3D"instal! > l -o roo > t -g wheel -m 444" /usr/bin/make -f Makefile -j4 = DESTDIR=3D/usr/obj/portswork/usr/ports/graphics/png/work/stage test; = then if [ x !=3D xTry to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before = reporting the failure to the maintainer. ] ; then echo "=3D=3D=3D> = Compilation failed unexpectedly."; (echo Try to set = MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the failure to the = maintainer.) | /usr/bin/fmt 75 79 ; fi; false; fi) > Running tests... > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) > *** [test] Error code 134 >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > 1 error >=20 > make[2]: stopped in = /usr/obj/portswork/usr/ports/graphics/png/work/libpng-1.6.16 > [: xTry: unexpected operator > *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/graphics/png > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/graphics/png >=20 >=20 > Even just ctest as a command gets the vector::reserve size problem = from the large magic number: >=20 > $ ctest > ********************************* > No test configuration file found! > ********************************* > terminate called after throwing an instance of 'std::length_error' > what(): vector::reserve > Abort trap (core dumped) >=20 >=20 > [So far I've only sidestepped having graphic/png run ctest to allow = some things that depend on graphics/png to not be blocked by this.] >=20 >=20 >=20 >=20 > For my context the overall environment has (but ports might force = other ports as alternatives to): >=20 > # more /etc/make.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > WRKDIRPREFIX=3D/usr/obj/portswork > WITH_DEBUG=3D > MALLOC_PRODUCTION=3D >=20 > # more /etc/src.conf > #CPP=3Dclang-cpp > #CC=3Dclang > #CXX=3Dclang++ > #CFLAGS+=3D-DELF_VERBOSE > #WITH_DEBUG_FILES=3D > #WITHOUT_CLANG=3D >=20 > # which cc > /usr/bin/cc >=20 > # cc --version > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There = is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >=20 > # which clang > /usr/bin/clang >=20 > # clang --version > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) = 20140512 > Target: powerpc64-unknown-freebsd10.1 > Thread model: posix >=20 >=20 >=20 >=20 >=20 > Other context details: >=20 > $ cd /usr/ports > $ svnlite info > Path: . > Working Copy Root Path: /usr/ports > URL: https://svn0.us-west.freebsd.org/ports/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 380683 > Node Kind: directory > Schedule: normal > Last Changed Author: demon > Last Changed Rev: 380683 > Last Changed Date: 2015-03-07 03:31:11 -0800 (Sat, 07 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > I distfiles > M graphics/libGL/bsd.mesalib.mk > I packages > ? restoresymtable >=20 > $ svnlite diff graphics/libGL/bsd.mesalib.mk > Index: graphics/libGL/bsd.mesalib.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- graphics/libGL/bsd.mesalib.mk (revision 380683) > +++ graphics/libGL/bsd.mesalib.mk (working copy) > @@ -136,6 +136,10 @@ > CONFIGURE_ARGS+=3D--enable-vdpau > .endif >=20 > +.if ${ARCH} =3D=3D powerpc64 > +CFLAGS+=3D -mminimal-toc > +.endif > + > post-patch: > @${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e = 's|x86_64|amd64|' \ > ${WRKSRC}/configure >=20 > $ cd /usr/src > $ svnlite info > Path: . > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/stable/10 > Relative URL: ^/stable/10 > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 279507 > Node Kind: directory > Schedule: normal > Last Changed Author: ngie > Last Changed Rev: 279507 > Last Changed Date: 2015-03-01 14:12:24 -0800 (Sun, 01 Mar 2015) >=20 > $ svnlite st --no-ignore > ? .snap > ? restoresymtable > M sys/ddb/db_main.c > M sys/ddb/db_script.c > I sys/powerpc/conf/GENERIC64vtsc > I sys/powerpc/conf/GENERICvtsc > M sys/powerpc/ofw/ofw_machdep.c > M sys/powerpc/ofw/ofwcall64.S > M sys/powerpc/powerpc/dump_machdep.c >=20 > sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to = avoid intermittent boot problems. >=20 > sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get = evidence if I do end up with another early-boot failure. DDB and GDB are = listed in sys/powerpc/conf/GENERIC64vtsc for the same reason. >=20 > sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer = size for dumps to be small enough not to be rejected as too large of a = DMA request size. >=20 > sys/powerpc/conf/GENERIC64vtsc turns off ps3 in order to turn on both = vt and sc. It includes the standard GENERIC64. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 9 03:23:37 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24D47709 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 D253919A for ; Mon, 9 Mar 2015 03:23:36 +0000 (UTC) Received: (qmail 8743 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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-ppc@FreeBSD.ORG Mon Mar 9 04:18:31 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A03C724F for ; Mon, 9 Mar 2015 04:18:31 +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 56F0686D for ; Mon, 9 Mar 2015 04:18:31 +0000 (UTC) Received: (qmail 3509 invoked from network); 9 Mar 2015 04:18:30 -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 04:18:30 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 09 Mar 2015 00:18:30 -0400 (EDT) Received: (qmail 23876 invoked from network); 9 Mar 2015 04:18:29 -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 04:18:29 -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 17ED31C43AA; Sun, 8 Mar 2015 21:18:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 10.1-STABLE kern.vty=vt crashes PowerMac G5 extremely early in boot for 2560x1440 display... From: Mark Millard In-Reply-To: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> Date: Sun, 8 Mar 2015 21:18:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> To: FreeBSD PowerPC ML , Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 04:18:31 -0000 Nathan W. write: > Could you please try -CURRENT? vt itself at least works fine there, = but=20 > I'm not sure anyone has tested it with such a large display on any = platform. > -Nathan I'll try. But it may take a bit to get a 11.0-CURRENT boot context = established: I've got the G5's doing other things at the moment. Looking at the -r279514 11.0-CURRENT code (see below) there seems a = VBF_STATIC flag for indicating a statically sized initial buffer. But = the code does not seem to use the static sized limits involved: instead = the code always seems to use the final sizes even before vtbuf_grow = toggles the flag's status. In other words: I expect that this goes goes out of bounds and trashes = memory it does not own while the static buffer is in use early on. #ifdef SC_HISTORY_SIZE #define VBF_DEFAULT_HISTORY_SIZE SC_HISTORY_SIZE #else #define VBF_DEFAULT_HISTORY_SIZE 500 #endif ... #ifndef VT_FB_DEFAULT_WIDTH #define VT_FB_DEFAULT_WIDTH 2048 #endif #ifndef VT_FB_DEFAULT_HEIGHT #define VT_FB_DEFAULT_HEIGHT 1200 #endif ... #define _VTDEFH MAX(100, PIXEL_HEIGHT(VT_FB_DEFAULT_HEIGHT)) #define _VTDEFW MAX(200, PIXEL_WIDTH(VT_FB_DEFAULT_WIDTH)) ... static term_char_t vt_constextbuf[(_VTDEFW) * = (VBF_DEFAULT_HISTORY_SIZE)]; static term_char_t *vt_constextbufrows[VBF_DEFAULT_HISTORY_SIZE]; static struct vt_window vt_conswindow =3D { .vw_number =3D VT_CONSWINDOW, .vw_flags =3D VWF_CONSOLE, .vw_buf =3D { .vb_buffer =3D &vt_constextbuf[0], .vb_rows =3D &vt_constextbufrows[0], .vb_history_size =3D VBF_DEFAULT_HISTORY_SIZE, .vb_curroffset =3D 0, .vb_roffset =3D 0, .vb_flags =3D VBF_STATIC, .vb_mark_start =3D {.tp_row =3D 0, .tp_col =3D 0,}, .vb_mark_end =3D {.tp_row =3D 0, .tp_col =3D 0,}, .vb_scr_size =3D { .tp_row =3D _VTDEFH, .tp_col =3D _VTDEFW, }, }, .vw_device =3D &vt_consdev, .vw_terminal =3D &vt_consterm, .vw_kbdmode =3D K_XLATE, .vw_grabbed =3D 0, }; ... void vtbuf_init_early(struct vt_buf *vb) { term_rect_t rect; vb->vb_flags |=3D VBF_CURSOR; vb->vb_roffset =3D 0; vb->vb_curroffset =3D 0; vb->vb_mark_start.tp_row =3D 0; vb->vb_mark_start.tp_col =3D 0; vb->vb_mark_end.tp_row =3D 0; vb->vb_mark_end.tp_col =3D 0; vtbuf_init_rows(vb); rect.tr_begin.tp_row =3D rect.tr_begin.tp_col =3D 0; rect.tr_end.tp_col =3D vb->vb_scr_size.tp_col; rect.tr_end.tp_row =3D vb->vb_history_size; vtbuf_fill(vb, &rect, VTBUF_SPACE_CHAR(TERMINAL_NORM_ATTR)); vtbuf_make_undirty(vb); if ((vb->vb_flags & VBF_MTX_INIT) =3D=3D 0) { mtx_init(&vb->vb_lock, "vtbuf", NULL, MTX_SPIN); vb->vb_flags |=3D VBF_MTX_INIT; } } ... static void vtbuf_fill(struct vt_buf *vb, const term_rect_t *r, term_char_t c) { unsigned int pr, pc; term_char_t *row; for (pr =3D r->tr_begin.tp_row; pr < r->tr_end.tp_row; pr++) { row =3D vb->vb_rows[(vb->vb_curroffset + pr) % VTBUF_MAX_HEIGHT(vb)]; for (pc =3D r->tr_begin.tp_col; pc < r->tr_end.tp_col; = pc++) { row[pc] =3D c; } } } ... static void vtbuf_init_rows(struct vt_buf *vb) { int r; =20 vb->vb_history_size =3D MAX(vb->vb_history_size, = vb->vb_scr_size.tp_row); =20 for (r =3D 0; r < vb->vb_history_size; r++) vb->vb_rows[r] =3D &vb->vb_buffer[r * = vb->vb_scr_size.tp_col]; } ... void vtbuf_init(struct vt_buf *vb, const term_pos_t *p) { int sz; vb->vb_scr_size =3D *p; vb->vb_history_size =3D VBF_DEFAULT_HISTORY_SIZE; if ((vb->vb_flags & VBF_STATIC) =3D=3D 0) { sz =3D vb->vb_history_size * p->tp_col * = sizeof(term_char_t); vb->vb_buffer =3D malloc(sz, M_VTBUF, M_WAITOK | = M_ZERO); sz =3D vb->vb_history_size * sizeof(term_char_t *); vb->vb_rows =3D malloc(sz, M_VTBUF, M_WAITOK | M_ZERO); } vtbuf_init_early(vb); } ... void vtbuf_grow(struct vt_buf *vb, const term_pos_t *p, unsigned int = history_size) { ... vb->vb_history_size =3D history_size; vb->vb_buffer =3D new; vb->vb_rows =3D rows; vb->vb_flags &=3D ~VBF_STATIC; vb->vb_scr_size =3D *p; vtbuf_init_rows(vb); ... =3D=3D=3D Mark Millard markmi@dsl-only.net On 2015-Mar-8, at 03:22 AM, Mark Millard wrote: Basic context: $ 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 The crash details (X11 is not part of the context, just console use): I tried using a 2560x1440 display with a PowerMac G5 but forgot to = switch from kern.vty=3Dvt to kern.vty=3Dsc in /boot/loader.conf first. But the result was new since the last time I'd done such a thing (long = ago)... It crashed so early that it returned to Apple's OpenFirmware. That allowed me to use .registers in OpenFirmware to find where it had = crashed at. It turned out that the Interrupt Vector was 0x700 and SRR0 was 0x380. = (Openfirmare does not put an exception handler at 0x380 (leaving zeros) = so a 0x380 exception handler's attempted use leads to a double fault = when OpenFirmware's handlers are all that are in place, the 2nd of the = pair going to the 0x700 exception handler.) Luckily LR is preserved in this sequence and it ended up pointing to: vtbuf_init_early+0x78 (0x40787c was the address for the build) and that was the instruction after a bl to .vtbuf_fill. This was fully repeatable. As conformation of the size dependency: Switching to a smaller display = booted fine (again fully repeatable). I'll note that kern.vty=3Dsc handles the 2560x1440 display fine for that = same PowerMac G5. sc uses most but not all of the width and it uses all = of the height. 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 PowerMac G5 specific change to avoid = intermittent boot problems. 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. 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/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. # 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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 9 05:00:44 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3F215A7; Mon, 9 Mar 2015 05:00:44 +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 C721AC83; Mon, 9 Mar 2015 05:00:44 +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 t2950Yxu003624 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Mar 2015 22:00:34 -0700 Message-ID: <54FD28F2.8050506@freebsd.org> Date: Sun, 08 Mar 2015 22:00:34 -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: Mark Millard , FreeBSD PowerPC ML , dumbbell@freebsd.org, ray@ddteam.net Subject: Re: 10.1-STABLE kern.vty=vt crashes PowerMac G5 extremely early in boot for 2560x1440 display... References: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVb8RvdoQ0ENl5IciswTyqb02k5uvQUQUIJHaD+bBhU/b5/Zf3wipaLK3zZ+GYwqEDNN6/DZbRQnS3vyTluJyW44oYJhLiexNYM= X-Sonic-ID: C;shHkNxnG5BGqZ75YxQPdhw== M;avsjOBnG5BGqZ75YxQPdhw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 05:00:45 -0000 Yes, I believe you are correct. That's an obvious bug that should be fixed. I've CC'ed a couple of the people working on the vt system. -Nathan On 03/08/15 21:18, Mark Millard wrote: > Nathan W. write: > >> Could you please try -CURRENT? vt itself at least works fine there, but >> I'm not sure anyone has tested it with such a large display on any platform. >> -Nathan > I'll try. But it may take a bit to get a 11.0-CURRENT boot context established: I've got the G5's doing other things at the moment. > > Looking at the -r279514 11.0-CURRENT code (see below) there seems a VBF_STATIC flag for indicating a statically sized initial buffer. But the code does not seem to use the static sized limits involved: instead the code always seems to use the final sizes even before vtbuf_grow toggles the flag's status. > > In other words: I expect that this goes goes out of bounds and trashes memory it does not own while the static buffer is in use early on. > > > #ifdef SC_HISTORY_SIZE > #define VBF_DEFAULT_HISTORY_SIZE SC_HISTORY_SIZE > #else > #define VBF_DEFAULT_HISTORY_SIZE 500 > #endif > ... > #ifndef VT_FB_DEFAULT_WIDTH > #define VT_FB_DEFAULT_WIDTH 2048 > #endif > #ifndef VT_FB_DEFAULT_HEIGHT > #define VT_FB_DEFAULT_HEIGHT 1200 > #endif > ... > > #define _VTDEFH MAX(100, PIXEL_HEIGHT(VT_FB_DEFAULT_HEIGHT)) > #define _VTDEFW MAX(200, PIXEL_WIDTH(VT_FB_DEFAULT_WIDTH)) > ... > static term_char_t vt_constextbuf[(_VTDEFW) * (VBF_DEFAULT_HISTORY_SIZE)]; > static term_char_t *vt_constextbufrows[VBF_DEFAULT_HISTORY_SIZE]; > static struct vt_window vt_conswindow = { > .vw_number = VT_CONSWINDOW, > .vw_flags = VWF_CONSOLE, > .vw_buf = { > .vb_buffer = &vt_constextbuf[0], > .vb_rows = &vt_constextbufrows[0], > .vb_history_size = VBF_DEFAULT_HISTORY_SIZE, > .vb_curroffset = 0, > .vb_roffset = 0, > .vb_flags = VBF_STATIC, > .vb_mark_start = {.tp_row = 0, .tp_col = 0,}, > .vb_mark_end = {.tp_row = 0, .tp_col = 0,}, > .vb_scr_size = { > .tp_row = _VTDEFH, > .tp_col = _VTDEFW, > }, > }, > .vw_device = &vt_consdev, > .vw_terminal = &vt_consterm, > .vw_kbdmode = K_XLATE, > .vw_grabbed = 0, > }; > > ... > > void > vtbuf_init_early(struct vt_buf *vb) > { > term_rect_t rect; > > vb->vb_flags |= VBF_CURSOR; > vb->vb_roffset = 0; > vb->vb_curroffset = 0; > vb->vb_mark_start.tp_row = 0; > vb->vb_mark_start.tp_col = 0; > vb->vb_mark_end.tp_row = 0; > vb->vb_mark_end.tp_col = 0; > > vtbuf_init_rows(vb); > rect.tr_begin.tp_row = rect.tr_begin.tp_col = 0; > rect.tr_end.tp_col = vb->vb_scr_size.tp_col; > rect.tr_end.tp_row = vb->vb_history_size; > vtbuf_fill(vb, &rect, VTBUF_SPACE_CHAR(TERMINAL_NORM_ATTR)); > vtbuf_make_undirty(vb); > if ((vb->vb_flags & VBF_MTX_INIT) == 0) { > mtx_init(&vb->vb_lock, "vtbuf", NULL, MTX_SPIN); > vb->vb_flags |= VBF_MTX_INIT; > } > } > ... > static void > vtbuf_fill(struct vt_buf *vb, const term_rect_t *r, term_char_t c) > { > unsigned int pr, pc; > term_char_t *row; > > for (pr = r->tr_begin.tp_row; pr < r->tr_end.tp_row; pr++) { > row = vb->vb_rows[(vb->vb_curroffset + pr) % > VTBUF_MAX_HEIGHT(vb)]; > for (pc = r->tr_begin.tp_col; pc < r->tr_end.tp_col; pc++) { > row[pc] = c; > } > } > } > ... > static void > vtbuf_init_rows(struct vt_buf *vb) > { > int r; > > vb->vb_history_size = MAX(vb->vb_history_size, vb->vb_scr_size.tp_row); > > for (r = 0; r < vb->vb_history_size; r++) > vb->vb_rows[r] = &vb->vb_buffer[r * vb->vb_scr_size.tp_col]; > } > ... > void > vtbuf_init(struct vt_buf *vb, const term_pos_t *p) > { > int sz; > > vb->vb_scr_size = *p; > vb->vb_history_size = VBF_DEFAULT_HISTORY_SIZE; > > if ((vb->vb_flags & VBF_STATIC) == 0) { > sz = vb->vb_history_size * p->tp_col * sizeof(term_char_t); > vb->vb_buffer = malloc(sz, M_VTBUF, M_WAITOK | M_ZERO); > > sz = vb->vb_history_size * sizeof(term_char_t *); > vb->vb_rows = malloc(sz, M_VTBUF, M_WAITOK | M_ZERO); > } > > vtbuf_init_early(vb); > } > ... > void > vtbuf_grow(struct vt_buf *vb, const term_pos_t *p, unsigned int history_size) > { > ... > vb->vb_history_size = history_size; > vb->vb_buffer = new; > vb->vb_rows = rows; > vb->vb_flags &= ~VBF_STATIC; > vb->vb_scr_size = *p; > vtbuf_init_rows(vb); > ... > > > > === > Mark Millard > markmi@dsl-only.net > > On 2015-Mar-8, at 03:22 AM, Mark Millard wrote: > > Basic context: > > $ 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 > > > The crash details (X11 is not part of the context, just console use): > > I tried using a 2560x1440 display with a PowerMac G5 but forgot to switch from kern.vty=vt to kern.vty=sc in /boot/loader.conf first. > > But the result was new since the last time I'd done such a thing (long ago)... > > It crashed so early that it returned to Apple's OpenFirmware. > > That allowed me to use .registers in OpenFirmware to find where it had crashed at. > > It turned out that the Interrupt Vector was 0x700 and SRR0 was 0x380. (Openfirmare does not put an exception handler at 0x380 (leaving zeros) so a 0x380 exception handler's attempted use leads to a double fault when OpenFirmware's handlers are all that are in place, the 2nd of the pair going to the 0x700 exception handler.) > > Luckily LR is preserved in this sequence and it ended up pointing to: > > vtbuf_init_early+0x78 (0x40787c was the address for the build) > > and that was the instruction after a bl to .vtbuf_fill. > > This was fully repeatable. > > > As conformation of the size dependency: Switching to a smaller display booted fine (again fully repeatable). > > > I'll note that kern.vty=sc handles the 2560x1440 display fine for that same PowerMac G5. sc uses most but not all of the width and it uses all of the height. > > > 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 PowerMac G5 specific change to avoid intermittent boot problems. > > 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. > > 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/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64. > > # more /etc/make.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > MALLOC_PRODUCTION= > > # more /etc/src.conf > #CPP=clang-cpp > #CC=clang > #CXX=clang++ > #CFLAGS+=-DELF_VERBOSE > #WITH_DEBUG_FILES= > #WITHOUT_CLANG > > === > Mark Millard > markmi at dsl-only.net > > > From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 9 06:44:51 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C3F7EB8 for ; Mon, 9 Mar 2015 06:44:51 +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 424A784F for ; Mon, 9 Mar 2015 06:44:50 +0000 (UTC) Received: (qmail 30884 invoked from network); 9 Mar 2015 06:44:43 -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 06:44:43 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Mon, 09 Mar 2015 02:44:43 -0400 (EDT) Received: (qmail 22274 invoked from network); 9 Mar 2015 06:44:43 -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 06:44:43 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 0ABE21C43A2; Sun, 8 Mar 2015 23:44:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: powerpc64 context, sysutils/polkit fails to build: broken pipe during /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py From: Mark Millard In-Reply-To: Date: Sun, 8 Mar 2015 23:44:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: freebsd-ports@freebsd.org, FreeBSD PowerPC ML , Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 06:44:51 -0000 Nathan W. wrote: > This builds without issue for me, both on a G5 system and on a POWER8. > -Nathan I decided to "pkg delete '*'", check /usr/local/... and /var/db/pkg/..., = and start a rebuild of all my ports to see what happens. The sysutils/polkit problem was gone. Other notes: I still had to configure graphics/png to not run its tests that make use = of cmake'c ctest. (This is just for powerpc64 builds: ctest works fine = for my powerpc builds.) powerpc64's ctest builds but crashes when run. graphics/libGL/bsd.mesalib.mk needed the powerpc64 patch that I included = in my context notes. The result built and using a PowerMac G5 with video hardware that was = historically supported and the same xorg.conf from long ago for that = same context basically worked for startxfce4. I could control-option Fn to get to a console but by the time I tried to = get back after that Xorg had died/quit. This was true for both vt and = sc. My X11 related powerpc (non-64) builds were stopped by... "CXXLD mesa_dri_drivers.la" gets "c++: Internal error: Segmentation = fault (program ld)" =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-7, at 10:16 PM, Mark Millard wrote: powerpc64 context (more details are listed later): $ 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 Ports Revision 380683 via svnlite update. I've been using portmaster. The problem (which I've not figured out yet)... x11/xorg, x11-drivers/xf86-video-ati-ums, x11-drivers/xf86-video-scfb, = and x11-wm/xfce4 are all blocked from building by sysutils/polkit = failing to build because of a broken pipe with a subprocess... ... gmake all-am gmake[6]: Entering directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' CC libpolkit_gobject_1_la-polkitenumtypes.lo CC libpolkit_gobject_1_la-polkitactiondescription.lo CC libpolkit_gobject_1_la-polkitauthorityfeatures.lo CC libpolkit_gobject_1_la-polkitdetails.lo CC libpolkit_gobject_1_la-polkitauthority.lo CC libpolkit_gobject_1_la-polkiterror.lo CC libpolkit_gobject_1_la-polkitsubject.lo CC libpolkit_gobject_1_la-polkitunixprocess.lo CC libpolkit_gobject_1_la-polkitsystembusname.lo CC libpolkit_gobject_1_la-polkitidentity.lo CC libpolkit_gobject_1_la-polkitunixuser.lo CC libpolkit_gobject_1_la-polkitunixgroup.lo CC libpolkit_gobject_1_la-polkitunixnetgroup.lo CC libpolkit_gobject_1_la-polkitauthorizationresult.lo CC libpolkit_gobject_1_la-polkitcheckauthorizationflags.lo CC libpolkit_gobject_1_la-polkitimplicitauthorization.lo CC libpolkit_gobject_1_la-polkittemporaryauthorization.lo CC libpolkit_gobject_1_la-polkitpermission.lo CC libpolkit_gobject_1_la-polkitunixsession.lo CCLD libpolkit-gobject-1.la GISCAN Polkit-1.0.gir Traceback (most recent call last): File "/usr/local/bin/g-ir-scanner", line 55, in sys.exit(scanner_main(sys.argv)) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 517, in scanner_main ss =3D create_source_scanner(options, args) File "/usr/local/lib/gobject-introspection/giscanner/scannermain.py", = line 430, in create_source_scanner ss.parse_files(filenames) File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", = line 256, in parse_files self._parse(headers) File "/usr/local/lib/gobject-introspection/giscanner/sourcescanner.py", = line 302, in _parse proc.stdin.write('#ifndef %s\n' % (define, )) IOError: [Errno 32] Broken pipe /usr/local/share/gobject-introspection-1.0/Makefile.introspection:153: = recipe for target 'Polkit-1.0.gir' failed gmake[6]: *** [Polkit-1.0.gir] Error 1 gmake[6]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:444: recipe for target 'all' failed gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src/polkit= ' Makefile:326: recipe for target 'all-recursive' failed gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105/src' Makefile:374: recipe for target 'all-recursive' failed gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' Makefile:305: recipe for target 'all' failed gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/polkit/work/polkit-0.105' *** Error code 1 Stop. make[1]: stopped in /usr/ports/sysutils/polkit *** Error code 1 Stop. make: stopped in /usr/ports/sysutils/polkit =3D=3D=3D>>> make build failed for sysutils/polkit =3D=3D=3D>>> Aborting update =3D=3D=3D>>> You can restart from the point of failure with this command = line: portmaster sysutils/polkit=20 The relevant = /usr/local/lib/gobject-introspection/giscanner/sourcescanner.py code = being... def _parse(self, filenames): if not filenames: return defines =3D ['__GI_SCANNER__'] undefs =3D [] cpp_args =3D os.environ.get('CC', 'cc').split() # support = CC=3D"ccache gcc" if 'cl' in cpp_args: # The Microsoft compiler/preprocessor (cl) does not accept # source input from stdin (the '-' flag), so we need # some help from gcc from MinGW/Cygwin or so. # Note that the generated dumper program is # still built and linked by Visual C++. cpp_args =3D ['gcc'] cpp_args +=3D os.environ.get('CPPFLAGS', '').split() cpp_args +=3D os.environ.get('CFLAGS', '').split() cpp_args +=3D ['-E', '-C', '-I.', '-'] cpp_args +=3D self._cpp_options proc =3D subprocess.Popen(cpp_args, stdin=3Dsubprocess.PIPE, stdout=3Dsubprocess.PIPE) for define in defines: proc.stdin.write('#ifndef %s\n' % (define, )) proc.stdin.write('# define %s\n' % (define, )) proc.stdin.write('#endif\n') ... For my context the overall environment has (but ports might force other = ports as alternatives to): # 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 # which cc /usr/bin/cc # 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. # which clang /usr/bin/clang # clang --version FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: powerpc64-unknown-freebsd10.1 Thread model: posix Other context details: $ 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 $ 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 PowerMac G5 specific change to avoid = intermittent boot problems. 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. 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/GENERIC64vtsc turns off ps3 in order to turn on both vt = and sc. It includes the standard GENERIC64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Mon Mar 9 15:09:17 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BBE0B297 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 6FA4C6D4 for ; Mon, 9 Mar 2015 15:09:16 +0000 (UTC) Received: (qmail 9982 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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-ppc@FreeBSD.ORG Tue Mar 10 12:51:54 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA333B96; Tue, 10 Mar 2015 12:51:53 +0000 (UTC) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 5278776C; Tue, 10 Mar 2015 12:51:52 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id D3131C4961; Tue, 10 Mar 2015 14:51:51 +0200 (EET) Date: Tue, 10 Mar 2015 14:52:55 +0200 From: Aleksandr Rybalko To: Nathan Whitehorn Subject: Re: 10.1-STABLE kern.vty=vt crashes PowerMac G5 extremely early in boot for 2560x1440 display... Message-Id: <20150310145255.c59c23381173c310229c9d82@ddteam.net> In-Reply-To: <54FD28F2.8050506@freebsd.org> References: <8B7B5167-0C94-4BA3-9515-B4CB8A817BDB@dsl-only.net> <54FD28F2.8050506@freebsd.org> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.25; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD PowerPC ML , dumbbell@freebsd.org, Mark Millard X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 12:51:54 -0000 On Sun, 08 Mar 2015 22:00:34 -0700 Nathan Whitehorn wrote: > Yes, I believe you are correct. That's an obvious bug that should be > fixed. I've CC'ed a couple of the people working on the vt system. > -Nathan > > On 03/08/15 21:18, Mark Millard wrote: > > Nathan W. write: > > > >> Could you please try -CURRENT? vt itself at least works fine there, but > >> I'm not sure anyone has tested it with such a large display on any platform. > >> -Nathan > > I'll try. But it may take a bit to get a 11.0-CURRENT boot context established: I've got the G5's doing other things at the moment. > > > > Looking at the -r279514 11.0-CURRENT code (see below) there seems a VBF_STATIC flag for indicating a statically sized initial buffer. But the code does not seem to use the static sized limits involved: instead the code always seems to use the final sizes even before vtbuf_grow toggles the flag's status. > > > > In other words: I expect that this goes goes out of bounds and trashes memory it does not own while the static buffer is in use early on. > > > > > > #ifdef SC_HISTORY_SIZE > > #define VBF_DEFAULT_HISTORY_SIZE SC_HISTORY_SIZE > > #else > > #define VBF_DEFAULT_HISTORY_SIZE 500 > > #endif > > ... > > #ifndef VT_FB_DEFAULT_WIDTH > > #define VT_FB_DEFAULT_WIDTH 2048 > > #endif > > #ifndef VT_FB_DEFAULT_HEIGHT > > #define VT_FB_DEFAULT_HEIGHT 1200 > > #endif > > ... > > > > #define _VTDEFH MAX(100, PIXEL_HEIGHT(VT_FB_DEFAULT_HEIGHT)) > > #define _VTDEFW MAX(200, PIXEL_WIDTH(VT_FB_DEFAULT_WIDTH)) > > ... > > static term_char_t vt_constextbuf[(_VTDEFW) * (VBF_DEFAULT_HISTORY_SIZE)]; > > static term_char_t *vt_constextbufrows[VBF_DEFAULT_HISTORY_SIZE]; > > static struct vt_window vt_conswindow = { > > .vw_number = VT_CONSWINDOW, > > .vw_flags = VWF_CONSOLE, > > .vw_buf = { > > .vb_buffer = &vt_constextbuf[0], > > .vb_rows = &vt_constextbufrows[0], > > .vb_history_size = VBF_DEFAULT_HISTORY_SIZE, > > .vb_curroffset = 0, > > .vb_roffset = 0, > > .vb_flags = VBF_STATIC, > > .vb_mark_start = {.tp_row = 0, .tp_col = 0,}, > > .vb_mark_end = {.tp_row = 0, .tp_col = 0,}, > > .vb_scr_size = { > > .tp_row = _VTDEFH, > > .tp_col = _VTDEFW, > > }, > > }, > > .vw_device = &vt_consdev, > > .vw_terminal = &vt_consterm, > > .vw_kbdmode = K_XLATE, > > .vw_grabbed = 0, > > }; > > > > ... > > > > void > > vtbuf_init_early(struct vt_buf *vb) > > { > > term_rect_t rect; > > > > vb->vb_flags |= VBF_CURSOR; > > vb->vb_roffset = 0; > > vb->vb_curroffset = 0; > > vb->vb_mark_start.tp_row = 0; > > vb->vb_mark_start.tp_col = 0; > > vb->vb_mark_end.tp_row = 0; > > vb->vb_mark_end.tp_col = 0; > > > > vtbuf_init_rows(vb); > > rect.tr_begin.tp_row = rect.tr_begin.tp_col = 0; > > rect.tr_end.tp_col = vb->vb_scr_size.tp_col; > > rect.tr_end.tp_row = vb->vb_history_size; > > vtbuf_fill(vb, &rect, VTBUF_SPACE_CHAR(TERMINAL_NORM_ATTR)); > > vtbuf_make_undirty(vb); > > if ((vb->vb_flags & VBF_MTX_INIT) == 0) { > > mtx_init(&vb->vb_lock, "vtbuf", NULL, MTX_SPIN); > > vb->vb_flags |= VBF_MTX_INIT; > > } > > } > > ... > > static void > > vtbuf_fill(struct vt_buf *vb, const term_rect_t *r, term_char_t c) > > { > > unsigned int pr, pc; > > term_char_t *row; > > > > for (pr = r->tr_begin.tp_row; pr < r->tr_end.tp_row; pr++) { > > row = vb->vb_rows[(vb->vb_curroffset + pr) % > > VTBUF_MAX_HEIGHT(vb)]; > > for (pc = r->tr_begin.tp_col; pc < r->tr_end.tp_col; pc++) { > > row[pc] = c; > > } > > } > > } > > ... > > static void > > vtbuf_init_rows(struct vt_buf *vb) > > { > > int r; > > > > vb->vb_history_size = MAX(vb->vb_history_size, vb->vb_scr_size.tp_row); > > > > for (r = 0; r < vb->vb_history_size; r++) > > vb->vb_rows[r] = &vb->vb_buffer[r * vb->vb_scr_size.tp_col]; > > } > > ... > > void > > vtbuf_init(struct vt_buf *vb, const term_pos_t *p) > > { > > int sz; > > > > vb->vb_scr_size = *p; > > vb->vb_history_size = VBF_DEFAULT_HISTORY_SIZE; > > > > if ((vb->vb_flags & VBF_STATIC) == 0) { > > sz = vb->vb_history_size * p->tp_col * sizeof(term_char_t); > > vb->vb_buffer = malloc(sz, M_VTBUF, M_WAITOK | M_ZERO); > > > > sz = vb->vb_history_size * sizeof(term_char_t *); > > vb->vb_rows = malloc(sz, M_VTBUF, M_WAITOK | M_ZERO); > > } > > > > vtbuf_init_early(vb); > > } > > ... > > void > > vtbuf_grow(struct vt_buf *vb, const term_pos_t *p, unsigned int history_size) > > { > > ... > > vb->vb_history_size = history_size; > > vb->vb_buffer = new; > > vb->vb_rows = rows; > > vb->vb_flags &= ~VBF_STATIC; > > vb->vb_scr_size = *p; > > vtbuf_init_rows(vb); > > ... > > > > > > > > === > > Mark Millard > > markmi@dsl-only.net > > > > On 2015-Mar-8, at 03:22 AM, Mark Millard wrote: > > > > Basic context: > > > > $ 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 > > > > > > The crash details (X11 is not part of the context, just console use): > > > > I tried using a 2560x1440 display with a PowerMac G5 but forgot to switch from kern.vty=vt to kern.vty=sc in /boot/loader.conf first. > > > > But the result was new since the last time I'd done such a thing (long ago)... > > > > It crashed so early that it returned to Apple's OpenFirmware. > > > > That allowed me to use .registers in OpenFirmware to find where it had crashed at. > > > > It turned out that the Interrupt Vector was 0x700 and SRR0 was 0x380. (Openfirmare does not put an exception handler at 0x380 (leaving zeros) so a 0x380 exception handler's attempted use leads to a double fault when OpenFirmware's handlers are all that are in place, the 2nd of the pair going to the 0x700 exception handler.) > > > > Luckily LR is preserved in this sequence and it ended up pointing to: > > > > vtbuf_init_early+0x78 (0x40787c was the address for the build) > > > > and that was the instruction after a bl to .vtbuf_fill. > > > > This was fully repeatable. > > > > > > As conformation of the size dependency: Switching to a smaller display booted fine (again fully repeatable). > > > > > > I'll note that kern.vty=sc handles the 2560x1440 display fine for that same PowerMac G5. sc uses most but not all of the width and it uses all of the height. > > > > > > 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 PowerMac G5 specific change to avoid intermittent boot problems. > > > > 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. > > > > 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/GENERIC64vtsc turns off ps3 in order to turn on both vt and sc. It includes the standard GENERIC64. > > > > # more /etc/make.conf > > #CPP=clang-cpp > > #CC=clang > > #CXX=clang++ > > WRKDIRPREFIX=/usr/obj/portswork > > WITH_DEBUG= > > MALLOC_PRODUCTION= > > > > # more /etc/src.conf > > #CPP=clang-cpp > > #CC=clang > > #CXX=clang++ > > #CFLAGS+=-DELF_VERBOSE > > #WITH_DEBUG_FILES= > > #WITHOUT_CLANG > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > > > > Hi guys! Mark, can you please try to add (or replace) options SC_HISTORY_SIZE=1000 to your kernel config? Looks like, it is history size problem and we need to set minimum size of history to at least (screen_height * 2) and check to not "grow" under this size. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-ppc@FreeBSD.ORG Tue Mar 10 20:12:03 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CF1F63D 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 32E5F8EC for ; Tue, 10 Mar 2015 20:12:02 +0000 (UTC) Received: (qmail 2380 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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-ppc@FreeBSD.ORG Wed Mar 11 14:06:42 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F523531 for ; Wed, 11 Mar 2015 14:06:42 +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 CC182AB for ; Wed, 11 Mar 2015 14:06:41 +0000 (UTC) Received: (qmail 13661 invoked from network); 11 Mar 2015 14:06:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Mar 2015 14:06:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 11 Mar 2015 10:06:39 -0400 (EDT) Received: (qmail 27722 invoked from network); 11 Mar 2015 14:06:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Mar 2015 14:06:39 -0000 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 9DE2E1C4052 for ; Wed, 11 Mar 2015 07:06:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc (non-64 variant) 11.0-CURRENT r279514->r279813 update's installworld failed to complete Message-Id: <39E807F1-4703-49A4-80DB-42784E6904B7@dsl-only.net> Date: Wed, 11 Mar 2015 07:06:36 -0700 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 14:06:42 -0000 A user experience report: I tried to take my recently constructed SSD = for booting $ 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 on PowerMacs and update a copy of it to -r279813 via: cd /usr/srcC/ svnlite update -r279813 make -j 8 buildworld kernel KERNCONF=3DGENERICvtsc-NODEBUG = INSTKERNNAME=3Dkernel11C make installworld But the installworld eventually failed with a Bus Error notice reported = after the line indicating /libexec/ld_elf.so.1 had been established... =3D>> libexec/rtld-elf/tests/target (install) ... /usr/libexec/ld-elf.so.1 -> /libexec/ld-elf.so.1 Bus error (core dumped) *** Error code 138 After that any attempt to load a program (say by typing ls) also got a = bus error. Already loaded programs continued to work from what I could = tell (such as the shell I was typing to). (This tracks when ld-elf.so.1 = would be involved vs. not.) Another attempt was to buildworld and buildkernel on one r279514 boot = SSD and to then installkernel and installworld via DESTDIR=3D/mnt to = another SSD. But /sbin/init got a Bus Error when booting the updated = SSD. I ended up reverting to an SSD where the -r279514 11.0-CURRENT kernel = and world had not been updated. I did not ever try substituting = ld-elf.so.1.old . This effort was made on a PowerMac G5 despite the non-64 status of the = build. (I have yet to build and install a powerpc64 variant of a fairly = recent 11.0-CURRENT snapshot.) I'm not likely to retry the experiment anytime soon. So I do not = directly have evidence of repeatability. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 12 00:12:44 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D0B0B7E for ; Thu, 12 Mar 2015 00:12:44 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CCE4B383 for ; Thu, 12 Mar 2015 00:12:43 +0000 (UTC) Received: (qmail 15406 invoked from network); 12 Mar 2015 00:12:36 -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 00:12:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 11 Mar 2015 20:12:36 -0400 (EDT) Received: (qmail 22131 invoked from network); 12 Mar 2015 00:12:36 -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 00:12:36 -0000 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 77F7F1C439E for ; Wed, 11 Mar 2015 17:12:30 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT: ofw_standard.c:175 (for example): attempts to cast char* to cell_t fail in cross compile from powerpc to powerpc64 Message-Id: Date: Wed, 11 Mar 2015 17:12:34 -0700 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:12:44 -0000 Basic context (on a PowerMac G5 but using a powerpc 11.0-CURRENT build = to cross build targeting powerpc64): # 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/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) The problem for building powerpc64 kernels from a powerpc build's = context... I tried to buildworld buildkernel with TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64. while buildworld completed buildkernel did not. I give the relevant part of the script output file below but the basic = problem shows up as point to integer conversions with mismatched sizes = in code casting (for example) char* to cell_t such as: static int ofw_std_test(ofw_t ofw, const char *name) { struct { cell_t name; cell_t nargs; cell_t nreturns; cell_t service; cell_t missing; } args =3D { (cell_t)"test", // <<<<<<<<<< LOOK HERE 1, 1, }; =20 args.service =3D (cell_t)name; // <<<<<<<<<< LOOK HERE if (openfirmware(&args) =3D=3D -1) return (-1); return (args.missing); } The script log shows: ... ctfconvert -L VERSION -g ofwbus.o^M cc -c -O -pipe -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-in clude-dirs -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-uninitialized -nostdinc -I. -I/usr/srcC/sys = -I/usr/srcC/sys/contrib/altq -I/usr/srcC/sys/contrib/libfdt -D_KERNEL = -DHAVE_KERNEL_OPTION _HEADERS -include opt_global.h -msoft-float -Wa,-many = -fno-omit-frame-pointer -mno-altivec -ffreestanding -fwrapv = -fstack-protector -gdwarf-2 -Wno-uninitialized -Wall -Wredundant-decls = -Wnested-exter ns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions = -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-uninitialized -fno-common -fms-extensions -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 = -msoft-float -std=3Diso9899:1999 -Werror /usr/srcC/sys/dev/ofw/ ofw_standard.c^M cc1: warnings being treated as errors^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_test':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:175: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:180: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_interpret':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:195: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:202: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_peer':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:226: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_child':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:248: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_parent':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:270: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_instance_to_package':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:292: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_getproplen':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:315: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:321: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_getprop':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:342: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:348: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:349: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_nextprop':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:370: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:376: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:377: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_setprop':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:399: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:405: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:406: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_canon':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:426: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:431: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:432: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_finddevice':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:450: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:455: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_instance_to_path':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:474: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:480: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_package_to_path':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:500: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:506: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_call_method':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:526: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:537: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_open':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:567: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:572: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_close':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:588: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_read':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:610: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:616: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_write':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:637: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:643: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_seek':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:663: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_claim':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:693: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:698: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:703: warning: cast to pointer from = integer of different size [-Wint-to-pointer-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:717: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:722: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:740: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:758: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M *** Error code 1^M ^M Stop.^M make[2]: stopped in = /usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERICvtsc-NODEBUG^M *** Error code 1^M ^M Stop.^M make[1]: stopped in /usr/srcC^M *** Error code 1^M =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 12 00:34:17 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BF61DF4 for ; Thu, 12 Mar 2015 00:34:17 +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 02EA07AF for ; Thu, 12 Mar 2015 00:34:16 +0000 (UTC) Received: (qmail 7574 invoked from network); 12 Mar 2015 00:34:15 -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 00:34:15 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 11 Mar 2015 20:34:15 -0400 (EDT) Received: (qmail 3068 invoked from network); 12 Mar 2015 00:34:15 -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 00:34:15 -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 950801C4052; Wed, 11 Mar 2015 17:34:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 11.0-CURRENT: ofw_standard.c:175 (for example): attempts to cast char* to cell_t fail in cross compile from powerpc to powerpc64 From: Mark Millard In-Reply-To: Date: Wed, 11 Mar 2015 17:34:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: FreeBSD PowerPC ML , Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:34:17 -0000 Given the mix of the new relocatable kernels, powerpc64 (and other > 32 = bit-bit addressed openfirmware use?) and "typedef uint32_t cell_t;" (at = least for sys/powerpc/include/ofw_machdep.h)... For the char*-to-cell_t casing in 11.0-CURRENT's ofw_standard.c to work = for powerpc64 and others with larger than 32 bit addresses but = restrictions in the openfirmware implementation it would seem that = something must force the strings to stay in lower memory where zero = extended 32 bit values work as addresses. (Which may well be a = requirement of the Openfirmware implementation --no matter how things = are expressed in C/C++ code.) On fundamentals it looks to me like the 11.0-CURRENT ofw_standard.c code = assumes that only a <=3D 32 bit pointer environment would be using = openfirmware: I see no hook for keeping the relevant strings inside the = smaller address range. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-11, at 05:12 PM, Mark Millard = wrote: Basic context (on a PowerMac G5 but using a powerpc 11.0-CURRENT build = to cross build targeting powerpc64): # 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/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) The problem for building powerpc64 kernels from a powerpc build's = context... I tried to buildworld buildkernel with TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64. while buildworld completed buildkernel did not. I give the relevant part of the script output file below but the basic = problem shows up as point to integer conversions with mismatched sizes = in code casting (for example) char* to cell_t such as: static int ofw_std_test(ofw_t ofw, const char *name) { struct { cell_t name; cell_t nargs; cell_t nreturns; cell_t service; cell_t missing; } args =3D { (cell_t)"test", // <<<<<<<<<< LOOK HERE 1, 1, }; args.service =3D (cell_t)name; // <<<<<<<<<< LOOK HERE if (openfirmware(&args) =3D=3D -1) return (-1); return (args.missing); } The script log shows: ... ctfconvert -L VERSION -g ofwbus.o^M cc -c -O -pipe -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-in clude-dirs -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-uninitialized -nostdinc -I. -I/usr/srcC/sys = -I/usr/srcC/sys/contrib/altq -I/usr/srcC/sys/contrib/libfdt -D_KERNEL = -DHAVE_KERNEL_OPTION _HEADERS -include opt_global.h -msoft-float -Wa,-many = -fno-omit-frame-pointer -mno-altivec -ffreestanding -fwrapv = -fstack-protector -gdwarf-2 -Wno-uninitialized -Wall -Wredundant-decls = -Wnested-exter ns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions = -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-uninitialized -fno-common -fms-extensions -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 = -msoft-float -std=3Diso9899:1999 -Werror /usr/srcC/sys/dev/ofw/ ofw_standard.c^M cc1: warnings being treated as errors^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_test':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:175: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:180: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_interpret':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:195: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:202: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_peer':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:226: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_child':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:248: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_parent':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:270: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_instance_to_package':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:292: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_getproplen':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:315: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:321: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_getprop':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:342: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:348: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:349: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_nextprop':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:370: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:376: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:377: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_setprop':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:399: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:405: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:406: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_canon':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:426: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:431: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:432: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_finddevice':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:450: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:455: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_instance_to_path':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:474: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:480: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_package_to_path':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:500: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:506: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_call_method':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:526: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:537: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_open':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:567: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:572: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_close':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:588: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_read':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:610: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:616: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_write':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:637: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:643: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_seek':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:663: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_claim':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:693: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:698: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:703: warning: cast to pointer from = integer of different size [-Wint-to-pointer-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:717: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c:722: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:740: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit':^M /usr/srcC/sys/dev/ofw/ofw_standard.c:758: warning: cast from pointer to = integer of different size [-Wpointer-to-int-cast]^M *** Error code 1^M ^M Stop.^M make[2]: stopped in = /usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERICvtsc-NODEBUG^M *** Error code 1^M ^M Stop.^M make[1]: stopped in /usr/srcC^M *** Error code 1^M =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 12 00:50:19 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1D7769 for ; Thu, 12 Mar 2015 00:50:19 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 C3CD28F5 for ; Thu, 12 Mar 2015 00:50:19 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id t2C0oF2o011535 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Mar 2015 17:50:15 -0700 Message-ID: <5500E2C7.7020903@freebsd.org> Date: Wed, 11 Mar 2015 17:50:15 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Mark Millard , FreeBSD PowerPC ML Subject: Re: 11.0-CURRENT: ofw_standard.c:175 (for example): attempts to cast char* to cell_t fail in cross compile from powerpc to powerpc64 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYlg/QsMXLwVc6O3Y7bm2FHc2zGagTLpj+4D4/hRrQOnCALhPaw66d1uFT07snvK2B6QCPv2NOiUIKNnuJLnQbsoRbeMC8I2ag= X-Sonic-ID: C;oFEcv1HI5BGLTe8Jj30JFw== M;vjJyv1HI5BGLTe8Jj30JFw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:50:20 -0000 That is indeed true (OF on PowerPC is 32-bit always). However, ofw_standard.c is not part of the 64-bit kernel since, as you note, it does not work on 64-bit PPC systems. I think you are building the wrong kernel here, or are using the wrong toolchain. In particular, I think you are trying to build GENERIC for powerpc64 (you need GENERIC64 instead). The build system is supposed to yell at you if you try to build GENERIC with a 64-bit toolchain, but it may have gotten confused by your cross-build environment. -Nathan On 03/11/15 17:34, Mark Millard wrote: > Given the mix of the new relocatable kernels, powerpc64 (and other > 32 bit-bit addressed openfirmware use?) and "typedef uint32_t cell_t;" (at least for sys/powerpc/include/ofw_machdep.h)... > > For the char*-to-cell_t casing in 11.0-CURRENT's ofw_standard.c to work for powerpc64 and others with larger than 32 bit addresses but restrictions in the openfirmware implementation it would seem that something must force the strings to stay in lower memory where zero extended 32 bit values work as addresses. (Which may well be a requirement of the Openfirmware implementation --no matter how things are expressed in C/C++ code.) > > On fundamentals it looks to me like the 11.0-CURRENT ofw_standard.c code assumes that only a <= 32 bit pointer environment would be using openfirmware: I see no hook for keeping the relevant strings inside the smaller address range. > > > === > Mark Millard > markmi at dsl-only.net > > On 2015-Mar-11, at 05:12 PM, Mark Millard wrote: > > Basic context (on a PowerMac G5 but using a powerpc 11.0-CURRENT build to cross build targeting powerpc64): > > # 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/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) > > > The problem for building powerpc64 kernels from a powerpc build's context... > > I tried to buildworld buildkernel with TARGET=powerpc TARGET_ARCH=powerpc64. while buildworld completed buildkernel did not. > > I give the relevant part of the script output file below but the basic problem shows up as point to integer conversions with mismatched sizes in code casting (for example) char* to cell_t such as: > > static int > ofw_std_test(ofw_t ofw, const char *name) > { > struct { > cell_t name; > cell_t nargs; > cell_t nreturns; > cell_t service; > cell_t missing; > } args = { > (cell_t)"test", // <<<<<<<<<< LOOK HERE > 1, > 1, > }; > > args.service = (cell_t)name; // <<<<<<<<<< LOOK HERE > if (openfirmware(&args) == -1) > return (-1); > return (args.missing); > } > > > The script log shows: > > ... > ctfconvert -L VERSION -g ofwbus.o^M > cc -c -O -pipe -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-in > clude-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-uninitialized -nostdinc -I. -I/usr/srcC/sys -I/usr/srcC/sys/contrib/altq -I/usr/srcC/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION > _HEADERS -include opt_global.h -msoft-float -Wa,-many -fno-omit-frame-pointer -mno-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wno-uninitialized -Wall -Wredundant-decls -Wnested-exter > ns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-uninitialized -fno-common -fms-extensions -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -msoft-float -std=iso9899:1999 -Werror /usr/srcC/sys/dev/ofw/ > ofw_standard.c^M > cc1: warnings being treated as errors^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_test':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:175: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:180: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_interpret':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:195: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:202: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_peer':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:226: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_child':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:248: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_parent':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:270: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_instance_to_package':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:292: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_getproplen':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:315: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:321: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_getprop':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:342: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:348: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:349: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_nextprop':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:370: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:376: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:377: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_setprop':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:399: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:405: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:406: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_canon':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:426: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:431: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:432: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_finddevice':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:450: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:455: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_instance_to_path':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:474: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:480: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_package_to_path':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:500: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:506: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_call_method':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:526: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:537: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_open':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:567: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:572: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_close':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:588: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_read':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:610: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:616: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_write':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:637: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:643: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_seek':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:663: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_claim':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:693: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:698: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:703: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:717: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:722: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:740: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:758: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]^M > *** Error code 1^M > ^M > Stop.^M > make[2]: stopped in /usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERICvtsc-NODEBUG^M > *** Error code 1^M > ^M > Stop.^M > make[1]: stopped in /usr/srcC^M > *** Error code 1^M > > > === > Mark Millard > markmi at dsl-only.net > > > From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 12 01:03:43 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C298288 for ; Thu, 12 Mar 2015 01:03: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 0D53AA71 for ; Thu, 12 Mar 2015 01:03:34 +0000 (UTC) Received: (qmail 29622 invoked from network); 12 Mar 2015 01:03:33 -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 01:03:33 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Wed, 11 Mar 2015 21:03:33 -0400 (EDT) Received: (qmail 15546 invoked from network); 12 Mar 2015 01:03:33 -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 01:03:33 -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 732FA1C439E; Wed, 11 Mar 2015 18:03:27 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: 11.0-CURRENT: ofw_standard.c:175 (for example): attempts to cast char* to cell_t fail in cross compile from powerpc to powerpc64 From: Mark Millard In-Reply-To: <5500E2C7.7020903@freebsd.org> Date: Wed, 11 Mar 2015 18:03:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6180F9D9-0D41-498A-A8CC-E4BAC7223627@dsl-only.net> References: <5500E2C7.7020903@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.2070.6) Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 01:03:43 -0000 You are right: Looking at the logs shows that I did not type all the = "64"s that I should have for the make command and I typed = GENERICvtsc-NODEBUG instead of GENERIC64vtsc-NODEBUG. So the only useful note from this mistake of mine is that the = environment does not catch the combination when tried from a powerpc = 11.0-CURRENT build. Rebulding... And thanks yet again. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-11, at 05:50 PM, Nathan Whitehorn wrote: That is indeed true (OF on PowerPC is 32-bit always). However, = ofw_standard.c is not part of the 64-bit kernel since, as you note, it = does not work on 64-bit PPC systems. I think you are building the wrong = kernel here, or are using the wrong toolchain. In particular, I think = you are trying to build GENERIC for powerpc64 (you need GENERIC64 = instead). The build system is supposed to yell at you if you try to = build GENERIC with a 64-bit toolchain, but it may have gotten confused = by your cross-build environment. -Nathan On 03/11/15 17:34, Mark Millard wrote: > Given the mix of the new relocatable kernels, powerpc64 (and other > = 32 bit-bit addressed openfirmware use?) and "typedef uint32_t cell_t;" = (at least for sys/powerpc/include/ofw_machdep.h)... >=20 > For the char*-to-cell_t casing in 11.0-CURRENT's ofw_standard.c to = work for powerpc64 and others with larger than 32 bit addresses but = restrictions in the openfirmware implementation it would seem that = something must force the strings to stay in lower memory where zero = extended 32 bit values work as addresses. (Which may well be a = requirement of the Openfirmware implementation --no matter how things = are expressed in C/C++ code.) >=20 > On fundamentals it looks to me like the 11.0-CURRENT ofw_standard.c = code assumes that only a <=3D 32 bit pointer environment would be using = openfirmware: I see no hook for keeping the relevant strings inside the = smaller address range. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2015-Mar-11, at 05:12 PM, Mark Millard = wrote: >=20 > Basic context (on a PowerMac G5 but using a powerpc 11.0-CURRENT build = to cross build targeting powerpc64): >=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/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) >=20 >=20 > The problem for building powerpc64 kernels from a powerpc build's = context... >=20 > I tried to buildworld buildkernel with TARGET=3Dpowerpc = TARGET_ARCH=3Dpowerpc64. while buildworld completed buildkernel did not. >=20 > I give the relevant part of the script output file below but the basic = problem shows up as point to integer conversions with mismatched sizes = in code casting (for example) char* to cell_t such as: >=20 > static int > ofw_std_test(ofw_t ofw, const char *name) > { > struct { > cell_t name; > cell_t nargs; > cell_t nreturns; > cell_t service; > cell_t missing; > } args =3D { > (cell_t)"test", // <<<<<<<<<< LOOK HERE > 1, > 1, > }; >=20 > args.service =3D (cell_t)name; // <<<<<<<<<< LOOK HERE > if (openfirmware(&args) =3D=3D -1) > return (-1); > return (args.missing); > } >=20 >=20 > The script log shows: >=20 > ... > ctfconvert -L VERSION -g ofwbus.o^M > cc -c -O -pipe -g -Wall -Wredundant-decls -Wnested-externs = -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-in > clude-dirs -fdiagnostics-show-option -Wno-unknown-pragmas = -Wno-uninitialized -nostdinc -I. -I/usr/srcC/sys = -I/usr/srcC/sys/contrib/altq -I/usr/srcC/sys/contrib/libfdt -D_KERNEL = -DHAVE_KERNEL_OPTION > _HEADERS -include opt_global.h -msoft-float -Wa,-many = -fno-omit-frame-pointer -mno-altivec -ffreestanding -fwrapv = -fstack-protector -gdwarf-2 -Wno-uninitialized -Wall -Wredundant-decls = -Wnested-exter > ns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline = -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions = -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas > -Wno-uninitialized -fno-common -fms-extensions -finline-limit=3D15000 = --param inline-unit-growth=3D100 --param large-function-growth=3D1000 = -msoft-float -std=3Diso9899:1999 -Werror /usr/srcC/sys/dev/ofw/ > ofw_standard.c^M > cc1: warnings being treated as errors^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_test':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:175: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:180: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_interpret':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:195: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:202: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_peer':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:226: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_child':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:248: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_parent':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:270: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_instance_to_package':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:292: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_getproplen':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:315: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:321: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_getprop':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:342: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:348: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:349: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_nextprop':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:370: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:376: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:377: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_setprop':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:399: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:405: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:406: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_canon':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:426: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:431: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:432: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_finddevice':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:450: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:455: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_instance_to_path':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:474: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:480: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_package_to_path':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:500: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:506: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function = 'ofw_std_call_method':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:526: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:537: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_open':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:567: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:572: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_close':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:588: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_read':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:610: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:616: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_write':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:637: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:643: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_seek':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:663: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_claim':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:693: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:698: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:703: warning: cast to pointer = from integer of different size [-Wint-to-pointer-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:717: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:722: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:740: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > /usr/srcC/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit':^M > /usr/srcC/sys/dev/ofw/ofw_standard.c:758: warning: cast from pointer = to integer of different size [-Wpointer-to-int-cast]^M > *** Error code 1^M > ^M > Stop.^M > make[2]: stopped in = /usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERICvtsc-NODEBUG^M > *** Error code 1^M > ^M > Stop.^M > make[1]: stopped in /usr/srcC^M > *** Error code 1^M >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 >=20 From owner-freebsd-ppc@FreeBSD.ORG Thu Mar 12 09:36:55 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C1DD833 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 14BD5AE0 for ; Thu, 12 Mar 2015 09:36:54 +0000 (UTC) Received: (qmail 8167 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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-ppc@FreeBSD.ORG Thu Mar 12 09:36:55 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C623835 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 16D66AE3 for ; Thu, 12 Mar 2015 09:36:54 +0000 (UTC) Received: (qmail 19343 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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-ppc@FreeBSD.ORG Thu Mar 12 12:00:39 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1F5B5BF for ; Thu, 12 Mar 2015 12:00:39 +0000 (UTC) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (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 BBD41D51 for ; Thu, 12 Mar 2015 12:00:39 +0000 (UTC) Received: by padet14 with SMTP id et14so20111006pad.0 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=hAk/d3XBCZYAzHyDGm09+Vq2kUs4liwn7k3saB/vwAdNLBvGUkI3hRIyjM1AqYP//W ge3iwIz3bDYiqhpfn1khTQG+7SQxDCjtxhoyTZGOhND+u11L6484346Hr56PeDjB8214 ZGUtpyKFmfrOmlpPVlFL/RQNkQ2xSnUrUW7hUV85pau4EhcChuN/AlRMkU+9QyNz0SiH Z5145CG+Hi/U0yxtHfuo0tWGwzBQY7gB4LyIE5RyBy1ymYsUz0p248UWlCcsDMpf6Fbt Zk/jJ754e8buAvgv2Jbe1MjfM1vamI5QFKIsWVNz7bP+xlb9tq8awTmhOJvrrKq2wJ36 0ekQ== X-Gm-Message-State: ALoCoQl1fv/xJdPk4bG9vzpm8t5vLbx4uFFIuAiAeBJ11W3zYEKNlbmrqdSY9O9h2paHs3lI8pGm 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 12:00:40 -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-ppc@FreeBSD.ORG Thu Mar 12 17:01:33 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6ACEC9DA 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 1F57F98E for ; Thu, 12 Mar 2015 17:01:32 +0000 (UTC) Received: (qmail 19269 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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-ppc@FreeBSD.ORG Thu Mar 12 17:04:59 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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-ppc@FreeBSD.ORG Thu Mar 12 19:18:56 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6BECA17 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 6ACD9BF8 for ; Thu, 12 Mar 2015 19:18:55 +0000 (UTC) Received: (qmail 3895 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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-ppc@FreeBSD.ORG Thu Mar 12 20:25:00 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E84473DF for ; Thu, 12 Mar 2015 20:25:00 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (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 B128368D for ; Thu, 12 Mar 2015 20:25:00 +0000 (UTC) Received: by padfb1 with SMTP id fb1so23268350pad.7 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=B6xNloJCFuT3psAonPiYOcfHe274YRmV/iTWIYdGZ3w8o6l86taAJtBFtILbv0J6+x G/4ASjriiroBXhjUX2qLPt52diRwMFqwQWbYPOVtHpbsktFKJ8TTxz9HdV8x/u1k9qfL dUGS61j7QV13N9So7BmsS+ArV784CGo6d959i1q0NFXYmahgVNp/iObsaAnN7dR0W/TH 3LtExPzH1Xh2Gor8PqxqNFEB9cd+S2WdLXN9LuJ+HJnkPHGvkXnKIjkaCIrr4G1Z1KPn h6cgY1WpOwCs+TsEJC8H31voYK8sIKNsVjgap4+UbV5r77Iztbz0XyrJK/tiuxKbUZtR 9tzg== X-Gm-Message-State: ALoCoQkeS2MuvowPCbtWKNCJPz9FeNeYmEJuO54gzt7OlBAl8P6CGQnGBOhseKHEWqffCjCIhfbm 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: Baptiste Daroussin , freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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-ppc@FreeBSD.ORG Thu Mar 12 20:42:43 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 634658D2 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 193D691B for ; Thu, 12 Mar 2015 20:42:42 +0000 (UTC) Received: (qmail 14210 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: Baptiste Daroussin , freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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-ppc@FreeBSD.ORG Thu Mar 12 21:33:08 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14C51400 for ; Thu, 12 Mar 2015 21:33:08 +0000 (UTC) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) (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 CFF39E28 for ; Thu, 12 Mar 2015 21:33:07 +0000 (UTC) Received: by pdbnh10 with SMTP id nh10so23231877pdb.3 for ; Thu, 12 Mar 2015 14:33:06 -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=SXf7oPF+4NRcWc344gv54QVub5gKYtUr2T6yCaAovplfuxZV01MVsbQ3hwR9/cGiC8 SVl5KG+02+jFWY7JSHVLAgXnXdf7rlgpeVaNbcLrucw0JYM2Yvb1vSFWgasxbTIg2pPH r6QwajvHsUA2/fkEPZ7N2a+Hhu3h41Xm5BNg2q8SwMfgeS7FWH/CU/RfH639VgDzooRv hWPpjhYqYamDSjf0YsM7YyJeBEP4jPpcoo2Z6cOZG1hLn/iXXGdpEap+uoEKZdd8w9Tj Koztz3t5VGQhIG9a2o26zhsqcQtudDvQ2k8eJNTG45/vWi4XDZk0aLZLWm1iKVOTdOEP OmNg== X-Gm-Message-State: ALoCoQlEPS+ocOSR5J5CNzXSaZYkoaKKNfzg4mUDK718pvdu4wVrfOnWnGUEgch1u3DoB+RIMh7S 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: Baptiste Daroussin , freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 21:33:08 -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-ppc@FreeBSD.ORG Thu Mar 12 22:13:53 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC92ECD6 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 6035C280 for ; Thu, 12 Mar 2015 22:13:52 +0000 (UTC) Received: (qmail 29258 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: Baptiste Daroussin , freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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-ppc@FreeBSD.ORG Thu Mar 12 22:44:52 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56E2AA8 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 F179D797 for ; Thu, 12 Mar 2015 22:44:51 +0000 (UTC) Received: (qmail 10124 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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-ppc@FreeBSD.ORG Fri Mar 13 03:44:09 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EC1DD7B8 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 9D42CF70 for ; Fri, 13 Mar 2015 03:44:09 +0000 (UTC) Received: (qmail 9991 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 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-ppc@FreeBSD.ORG Fri Mar 13 23:04:33 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 686E5CC1 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 1A66762F for ; Fri, 13 Mar 2015 23:04:32 +0000 (UTC) Received: (qmail 20516 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: Baptiste Daroussin , freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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-ppc@FreeBSD.ORG Sat Mar 14 05:43:11 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90C2C8FA 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 4CE55FC7 for ; Sat, 14 Mar 2015 05:43:10 +0000 (UTC) Received: (qmail 9770 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-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 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