From owner-freebsd-ppc@freebsd.org Sun Apr 24 00:21:05 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2261B1AD6A for ; Sun, 24 Apr 2016 00:21:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-159.reflexion.net [208.70.211.159]) (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 67E211F07 for ; Sun, 24 Apr 2016 00:21:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9159 invoked from network); 24 Apr 2016 00:21:30 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Apr 2016 00:21:30 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 23 Apr 2016 20:21:08 -0400 (EDT) Received: (qmail 374 invoked from network); 24 Apr 2016 00:21:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 Apr 2016 00:21:07 -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-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B11EFB1E001; Sat, 23 Apr 2016 17:20:57 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? From: Mark Millard In-Reply-To: <571C0297.3050801@FreeBSD.org> Date: Sat, 23 Apr 2016 17:21:02 -0700 Cc: FreeBSD PowerPC ML , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> To: Steve Wills X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 00:21:05 -0000 On 2016-Apr-23, at 4:17 PM, Steve Wills wrote: >=20 > Hi, >=20 > On 04/23/16 05:50 PM, Mark Millard wrote: >> Recently a large block of ports (including lang/gcc6-devel) were >> marked in their Makefiles with >>=20 >>> BROKEN_powerpc64=3D Does not build >>=20 >>=20 >> Does this only apply for use of gcc/g++ 4.2.1 or specific other >> verions? If so that is not the only way to have a powerpc64 >> environment. For example: how "official" is use of >> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and >> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)?=20 >=20 >=20 > The intent was just that they don't build with the default config, ie, > gcc 4.2.1 from base. If there are ways to make things build with other > compilers, we should look at getting those changes into ports. >=20 > You can find the logs of the build that I based all those changes on = here: >=20 > = http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower= pc-default&build=3D2016-04-02_20h57m16s >=20 > Specifically the gcc6-devel one is here: >=20 > = http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-= 02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log >=20 > Though I realize now that was simply a timeout and perhaps shouldn't > have been marked as broken. A few of the llvm ones timed out and I > didn't mark those as broken and meant to not mark any that timed out = as > broken, and to go back and retry them, but didn't notice this one was = a > timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it > builds for you. Since my original note -r413919 has updated devel/gcc6-devel. So I'll = end up testing that update once I get to that point. I'll note that the svn-ports-head entry for -r412746 lists several llvm = items: head/devel/llvm-cheri/Makefile head/devel/llvm-devel/Makefile head/devel/llvm33/Makefile head/devel/llvm34/Makefile head/devel/llvm38/Makefile But I do not build any of those normally. llvm38 likely is toolchain = vintage dependent for if it builds or not. Others may be as well. > Also note that build was using the 2016Q2 branch, but the > BROKEN_powerpc64 was committed to the main branch. Perhaps that change > should be merged to the 2016Q2 branch. >=20 > Anyway, I'm currently retrying the build, after fixing pixman and > merging that to the 2016Q2 and then locally patching in the > BROKEN_powerpc64 things into my local tree. You can see the progress = of > that here: >=20 > = http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower= pc-default&build=3D2016-04-21_17h38m55s >=20 >=20 >> Can broken be marked for only specific tool chains? >>=20 >=20 > Not trivially, but it's probably doable somehow. >=20 >>> # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU=20 >>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M: >>> Sat Apr 9 22:22:19 PDT 2016 >>> = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG >>> powerpc 1100105 1100105 >>=20 >> For the rest of this note I'll focus on lang/gcc-devel since I happen >> to build and install it. >>=20 >>> # pkg info '*gcc*' gcc49-4.9.4.s20160406=20 >>> gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0=20 >>> powerpc64-xtoolchain-gcc-0.1 >>=20 >> gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on the >> that same old PowerMac. -r413188 is the prior lang/gcc-devel check in >> before being marked broken for powerpc64. For how I build it was not >> broken at the time. >>=20 >> I historically use devel/powerpc64-xtoolchain-gcc (so >> devel/powerpc64-gcc as well) for the so-called "cross build" stages >> of buildworld/buildkernel (11.0-CURRENT). (I also do true cross >> builds for TARGET_ARCH=3Dpowerpc64 from an amd64 context sometimes.) >>=20 >> gcc 4.2.1 is not present before, during, or after on the old >> PowerMac. I do build clang and various related materials but do not >> use clang for buildworld/buildkernel related activity. I experiment >> with using clang for other things at times. >>=20 >> I historically use lang/gcc49 on the old PowerMac for: >>=20 >> A) building devel/powerpc64-gcc (not the only way to try to build >> it) B) the "host" stages of buildworld/buildkernel (11.0-CURRENT) C) >> building lang/gcc6-devel (not the only way to try to build it) >>=20 >> [I do not have lang/gcc5 built/installed only because it and >> devel/powerpc64-gcc have file conflicts when they are based on the >> same gcc version. Getting devel/powerpc64-gcc to build and install on >> a powerpc64 requires some workarounds because it is not a true cross >> compile environment and some file names are odd for self-hosted and >> so not found during staging's copy activities.] >>=20 >> [I do build the system's clang 3.8.0 but do not use it other than for >> exploring/checking its current powerpc64 FreeBSD limitations. It does >> work for various things but not everything. Those experiments do not >> include buildworld or buildkernel. For example: clang 3.8.0 targeting >> powerpc64 can not build libstand due to lack of software floating >> point support. C++ exception handling built via clang for powerpc64 >> is messed up as well.] >>=20 >>=20 >=20 > It would be nice if we could fix those things and get powerpc(64) = built > with clang. https://llvm.org/bugs/show_bug.cgi?id=3D25780 [a meta-list of reports = that block use by freebsd] lists various powerpc and powerpc64 = code-generation issues for clang 3.8.0 vs. FreeBSD. As I remember each = of the following includes examples of powerpc64 code-generation issues, = not just powerpc (non-64) ones. https://llvm.org/bugs/show_bug.cgi?id=3D26970 https://llvm.org/bugs/show_bug.cgi?id=3D26856 https://llvm.org/bugs/show_bug.cgi?id=3D26844 https://llvm.org/bugs/show_bug.cgi?id=3D26761 (I also submitted reports to freebsd as well so there would be reminders = to track clang fixes if they ever occur. There may be more issues than I = reported in either place.) As I remember I thought there were also some FreeBSD problems that would = be present after the above were fixed but the code generation problems = made it harder to be sure. Even if I was correct any testing based on = the bad code-generation by clang in overlapping areas would not work. = I'd prefer to recheck/reanalyze based on seeing good code generation = results. Unfortunately while I can slowly analyze/research the code generated it = would take a lot longer to get the point of doing non-trival work on = llvm or clang itself. And since somewhat after clang 3.8.0 moved into = 11.0-CURRENT other things have kept me mostly out of clang = investigations. I've just been rebuilding FreeBSD and some ports = periodically in order to avoid large jumps later. >>=20 >> I have started a powerpc64 self-hosted buildworld/buildkernel for an >> update to 11.0-CURRENT -r298518 in preparation for then updating my >> ports to -r413907 or so. >>=20 >> My intent is to comment out the BROKEN_powerpc64 line in >> lang/gcc6-devel/Makefile and see if lang/gcc6-devel still (re-)builds >> once everything else is up to date. >>=20 >> But the builds involved take many hours so I'll likely not have a >> result to report until tomorrow (or later). >>=20 >>=20 >> Supporting example details: >>=20 >>> # svnlite info /usr/ports Path: /usr/ports Working Copy Root Path: >>> /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head=20 >>> Relative URL: ^/head Repository Root: >>> https://svn0.us-west.freebsd.org/ports Repository UUID: >>> 35697150-7ecd-e111-bb59-0022644237b5 Revision: 413230 Node Kind: >>> directory Schedule: normal Last Changed Author: kmoore Last Changed >>> Rev: 413230 Last Changed Date: 2016-04-13 13:07:37 -0700 (Wed, 13 >>> Apr 2016) >>=20 >> (I'll svnlite update -r413907 /usr/ports [or there about] after the >> system is updated. The above was used for my existing lang/gcc-devel >> build on powerpc64 for powerpc64.) >>=20 >>> # more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20 >>> WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D=20= >>> MALLOC_PRODUCTION=3D # # # For trying gcc49... #=20 >>> CC=3D/usr/local/bin/gcc49 CXX=3D/usr/local/bin/g++49=20 >>> CPP=3D/usr/local/bin/cpp49 # # # For trying port binutils... #=20 >>> CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ >>>=20 >>>=20 > AS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/as >>> AR=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ar=20 >>> LD=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ld=20 >>> NM=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/nm=20 >>> OBJCOPY=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy=20 >>> OBJDUMP=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump=20 >>> RANLIB=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib=20 >>> SIZE=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/size #NO-SUCH: >>> STRINGS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/strings=20 >>> STRINGS=3D/usr/local/bin/strings >>=20 >> The above sort of make.conf is used for port builds, though I may >> edit the details to control my experiments. >>=20 >> The below are tied to buildworld/buildkernel related activity: >>=20 >>> # more >>> = /root/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_cla= ng_xtoolchain-powerpc64-host.sh >>> script >>> = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain-powerpc64-host-$(date >>> +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" >>> = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-= host" >>> \ MAKEOBJDIRPREFIX=3D"/usr/obj/xtoolchain/powerpc.powerpc64" \ make >>> $* >>=20 >>=20 >> /root/src.configs/make.conf (used for buildworld/buildkernel) is >> normally empty. >>=20 >>> # more >>> /root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host=20 >>> TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3Dpowerpc64=20= >>> TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D11.0 #=20 >>> KERNCONF=3DGENERIC64vtsc-NODEBUG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} = =3D=3D >>> 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif #=20 >>> WITHOUT_CROSS_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D=20 >>> #WITH_LIB32=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D=20= >>> WITH_LLDB=3D # # LIB32 builds but does not work via gcc variants >>> [crtbeginS code problem(s)] WITHOUT_LIB32=3D WITHOUT_GCC=3D=20 >>> WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D #=20 >>> WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # >>> So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # >>> TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils. >>> . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc=20 >>> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if >>> ${.MAKE.LEVEL} =3D=3D 0=20 >>> = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c >>>=20 >>>=20 > = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ >>> = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp >>>=20 >>>=20 > .export XCC >>> .export XCXX .export XCPP=20 >>> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as=20 >>> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar=20 >>> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld=20 >>> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm=20 >>> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy=20 >>> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump=20 >>> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib=20 >>> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: >>> XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings=20 >>> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export >>> XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export >>> XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # #=20= >>> # For FROM (host) stages . . . # =46rom gccXY (such as gcc49 but not >>> xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if >>> ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include >>> /usr/local/bin/gcc49 -L/usr/lib CXX=3Denv = C_INCLUDE_PATH=3D/usr/include >>> CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 >>> -std=3Dc++11 -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp49 = .export >>> CC .export CXX .export CPP=20 >>> = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s >>>=20 >>>=20 > = AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= r >>> = LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l= d >>>=20 >>>=20 > = NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n= m >>> = OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objcopy >>>=20 >>>=20 > = OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objdump >>> = RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/ranlib >>>=20 >>>=20 > = SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin= /size >>> #NO-SUCH: >>> = STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/strings >>>=20 >>>=20 > STRINGS=3D/usr/local/bin/strings >>> .export AS .export AR .export LD .export NM .export OBJCOPY .export >>> OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif >>=20 >>> # svnlite status /usr/src ? /usr/src/.snap M >>> = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>>=20 >>>=20 > M /usr/src/lib/csu/powerpc64/Makefile >>> ? /usr/src/restoresymtable ? >>> /usr/src/sys/arm/conf/RPI2-NODBG M >>> /usr/src/sys/boot/ofw/Makefile.inc M >>> /usr/src/sys/boot/powerpc/Makefile M >>> /usr/src/sys/boot/powerpc/Makefile.inc M >>> /usr/src/sys/boot/uboot/Makefile.inc M >>> /usr/src/sys/conf/Makefile.powerpc M >>> /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk ? >>> /usr/src/sys/powerpc/conf/GENERIC64-NODBG ? >>> /usr/src/sys/powerpc/conf/GENERIC64vtsc ? >>> /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? >>> /usr/src/sys/powerpc/conf/GENERICvtsc ? >>> /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG M >>> /usr/src/sys/powerpc/ofw/ofw_machdep.c M >>> /usr/src/sys/powerpc/powerpc/exec_machdep.c >>=20 >>=20 >=20 > Let me know what you find. There was some work on external compiler > support, though I don't know it's current status. My powerpc64 FreeBSD activity is completely dependent on the external = compiler support: I'm using FreeBSD's modern libc++, not libstdc++. But = there are some workarounds involved for my complete avoidance of gcc = 4.2.1. I've a few other work arounds for the PowerMac context as well. = For example: downloaded release and snapshot installations do not = reliably boot such PowerMacs but instead frequently hang during boot. = (The frequency may depend on the amount of RAM.) I'll let you know how the updated devel/gcc6-devel goes for my style of = powerpc64 environment. If a devel/gcc6 appears I'll likely build it at some point. > Steve =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Apr 24 07:20:53 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B57CB198F1 for ; Sun, 24 Apr 2016 07:20:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-158.reflexion.net [208.70.211.158]) (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 6092F1E21 for ; Sun, 24 Apr 2016 07:20:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14779 invoked from network); 24 Apr 2016 07:21:16 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Apr 2016 07:21:16 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 24 Apr 2016 03:20:56 -0400 (EDT) Received: (qmail 4302 invoked from network); 24 Apr 2016 07:20:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 Apr 2016 07:20:55 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8869F1C4388; Sun, 24 Apr 2016 00:19:32 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? From: Mark Millard In-Reply-To: <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> Date: Sun, 24 Apr 2016 00:19:32 -0700 Cc: FreeBSD PowerPC ML , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> To: Steve Wills X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 07:20:53 -0000 [A top-post of the results of my test build of lang/gcc6-devel using = gcc49 to do the build (until it switches over to xgcc). I do not have = lang/gcc or lang/gcc48 installed.] lang/gcc6-devel's update built fine in my = powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a = powerpc64 PowerMac. The options were as I normally use: > # more /var/db/ports/lang_gcc6-devel/options > # This file is auto-generated by 'make config'. > # Options for gcc6-devel-6.0.0.s20160110 > _OPTIONS_READ=3Dgcc6-devel-6.0.0.s20160110 > _FILE_COMPLETE_OPTIONS_LIST=3DBOOTSTRAP GRAPHITE JAVA MULTILIB > OPTIONS_FILE_UNSET+=3DBOOTSTRAP > OPTIONS_FILE_UNSET+=3DGRAPHITE > OPTIONS_FILE_UNSET+=3DJAVA > OPTIONS_FILE_UNSET+=3DMULTILIB I will note that ruby is implicitly in use in my environment and it too = had been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , and = lang/ruby23 all were so marked. (So I commented those marks out.) My build that upgraded from ruby21 to ruby22 went fine. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-23, at 5:21 PM, Mark Millard wrote: >=20 > On 2016-Apr-23, at 4:17 PM, Steve Wills wrote: >>=20 >> Hi, >>=20 >> On 04/23/16 05:50 PM, Mark Millard wrote: >>> Recently a large block of ports (including lang/gcc6-devel) were >>> marked in their Makefiles with >>>=20 >>>> BROKEN_powerpc64=3D Does not build >>>=20 >>>=20 >>> Does this only apply for use of gcc/g++ 4.2.1 or specific other >>> verions? If so that is not the only way to have a powerpc64 >>> environment. For example: how "official" is use of >>> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and >>> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)?=20 >>=20 >>=20 >> The intent was just that they don't build with the default config, = ie, >> gcc 4.2.1 from base. If there are ways to make things build with = other >> compilers, we should look at getting those changes into ports. >>=20 >> You can find the logs of the build that I based all those changes on = here: >>=20 >> = http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower= pc-default&build=3D2016-04-02_20h57m16s >>=20 >> Specifically the gcc6-devel one is here: >>=20 >> = http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-= 02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log >>=20 >> Though I realize now that was simply a timeout and perhaps shouldn't >> have been marked as broken. A few of the llvm ones timed out and I >> didn't mark those as broken and meant to not mark any that timed out = as >> broken, and to go back and retry them, but didn't notice this one was = a >> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it >> builds for you. >=20 > Since my original note -r413919 has updated devel/gcc6-devel. So I'll = end up testing that update once I get to that point. >=20 > I'll note that the svn-ports-head entry for -r412746 lists several = llvm items: >=20 > head/devel/llvm-cheri/Makefile > head/devel/llvm-devel/Makefile > head/devel/llvm33/Makefile > head/devel/llvm34/Makefile > head/devel/llvm38/Makefile >=20 > But I do not build any of those normally. llvm38 likely is toolchain = vintage dependent for if it builds or not. Others may be as well. >=20 >> Also note that build was using the 2016Q2 branch, but the >> BROKEN_powerpc64 was committed to the main branch. Perhaps that = change >> should be merged to the 2016Q2 branch. >>=20 >> Anyway, I'm currently retrying the build, after fixing pixman and >> merging that to the 2016Q2 and then locally patching in the >> BROKEN_powerpc64 things into my local tree. You can see the progress = of >> that here: >>=20 >> = http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower= pc-default&build=3D2016-04-21_17h38m55s >>=20 >>=20 >>> Can broken be marked for only specific tool chains? >>>=20 >>=20 >> Not trivially, but it's probably doable somehow. >>=20 >>>> # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU=20 >>>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M: >>>> Sat Apr 9 22:22:19 PDT 2016 >>>> = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG >>>> powerpc 1100105 1100105 >>>=20 >>> For the rest of this note I'll focus on lang/gcc-devel since I = happen >>> to build and install it. >>>=20 >>>> # pkg info '*gcc*' gcc49-4.9.4.s20160406=20 >>>> gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0=20 >>>> powerpc64-xtoolchain-gcc-0.1 >>>=20 >>> gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on the >>> that same old PowerMac. -r413188 is the prior lang/gcc-devel check = in >>> before being marked broken for powerpc64. For how I build it was not >>> broken at the time. >>>=20 >>> I historically use devel/powerpc64-xtoolchain-gcc (so >>> devel/powerpc64-gcc as well) for the so-called "cross build" stages >>> of buildworld/buildkernel (11.0-CURRENT). (I also do true cross >>> builds for TARGET_ARCH=3Dpowerpc64 from an amd64 context sometimes.) >>>=20 >>> gcc 4.2.1 is not present before, during, or after on the old >>> PowerMac. I do build clang and various related materials but do not >>> use clang for buildworld/buildkernel related activity. I experiment >>> with using clang for other things at times. >>>=20 >>> I historically use lang/gcc49 on the old PowerMac for: >>>=20 >>> A) building devel/powerpc64-gcc (not the only way to try to build >>> it) B) the "host" stages of buildworld/buildkernel (11.0-CURRENT) C) >>> building lang/gcc6-devel (not the only way to try to build it) >>>=20 >>> [I do not have lang/gcc5 built/installed only because it and >>> devel/powerpc64-gcc have file conflicts when they are based on the >>> same gcc version. Getting devel/powerpc64-gcc to build and install = on >>> a powerpc64 requires some workarounds because it is not a true cross >>> compile environment and some file names are odd for self-hosted and >>> so not found during staging's copy activities.] >>>=20 >>> [I do build the system's clang 3.8.0 but do not use it other than = for >>> exploring/checking its current powerpc64 FreeBSD limitations. It = does >>> work for various things but not everything. Those experiments do not >>> include buildworld or buildkernel. For example: clang 3.8.0 = targeting >>> powerpc64 can not build libstand due to lack of software floating >>> point support. C++ exception handling built via clang for powerpc64 >>> is messed up as well.] >>>=20 >>>=20 >>=20 >> It would be nice if we could fix those things and get powerpc(64) = built >> with clang. >=20 > https://llvm.org/bugs/show_bug.cgi?id=3D25780 [a meta-list of reports = that block use by freebsd] lists various powerpc and powerpc64 = code-generation issues for clang 3.8.0 vs. FreeBSD. As I remember each = of the following includes examples of powerpc64 code-generation issues, = not just powerpc (non-64) ones. >=20 > https://llvm.org/bugs/show_bug.cgi?id=3D26970 > https://llvm.org/bugs/show_bug.cgi?id=3D26856 > https://llvm.org/bugs/show_bug.cgi?id=3D26844 > https://llvm.org/bugs/show_bug.cgi?id=3D26761 >=20 > (I also submitted reports to freebsd as well so there would be = reminders to track clang fixes if they ever occur. There may be more = issues than I reported in either place.) >=20 > As I remember I thought there were also some FreeBSD problems that = would be present after the above were fixed but the code generation = problems made it harder to be sure. Even if I was correct any testing = based on the bad code-generation by clang in overlapping areas would not = work. I'd prefer to recheck/reanalyze based on seeing good code = generation results. >=20 > Unfortunately while I can slowly analyze/research the code generated = it would take a lot longer to get the point of doing non-trival work on = llvm or clang itself. And since somewhat after clang 3.8.0 moved into = 11.0-CURRENT other things have kept me mostly out of clang = investigations. I've just been rebuilding FreeBSD and some ports = periodically in order to avoid large jumps later. >=20 >=20 >>>=20 >>> I have started a powerpc64 self-hosted buildworld/buildkernel for an >>> update to 11.0-CURRENT -r298518 in preparation for then updating my >>> ports to -r413907 or so. >>>=20 >>> My intent is to comment out the BROKEN_powerpc64 line in >>> lang/gcc6-devel/Makefile and see if lang/gcc6-devel still = (re-)builds >>> once everything else is up to date. >>>=20 >>> But the builds involved take many hours so I'll likely not have a >>> result to report until tomorrow (or later). >>>=20 >>>=20 >>> Supporting example details: >>>=20 >>>> # svnlite info /usr/ports Path: /usr/ports Working Copy Root Path: >>>> /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head=20 >>>> Relative URL: ^/head Repository Root: >>>> https://svn0.us-west.freebsd.org/ports Repository UUID: >>>> 35697150-7ecd-e111-bb59-0022644237b5 Revision: 413230 Node Kind: >>>> directory Schedule: normal Last Changed Author: kmoore Last Changed >>>> Rev: 413230 Last Changed Date: 2016-04-13 13:07:37 -0700 (Wed, 13 >>>> Apr 2016) >>>=20 >>> (I'll svnlite update -r413907 /usr/ports [or there about] after the >>> system is updated. The above was used for my existing lang/gcc-devel >>> build on powerpc64 for powerpc64.) >>>=20 >>>> # more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20 >>>> WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D=20= >>>> MALLOC_PRODUCTION=3D # # # For trying gcc49... #=20 >>>> CC=3D/usr/local/bin/gcc49 CXX=3D/usr/local/bin/g++49=20 >>>> CPP=3D/usr/local/bin/cpp49 # # # For trying port binutils... #=20 >>>> CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/= >>>>=20 >>>>=20 >> AS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/as >>>> AR=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ar=20 >>>> LD=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ld=20 >>>> NM=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/nm=20 >>>> OBJCOPY=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy=20 >>>> OBJDUMP=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump=20 >>>> RANLIB=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib=20 >>>> SIZE=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/size #NO-SUCH: >>>> STRINGS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/strings=20 >>>> STRINGS=3D/usr/local/bin/strings >>>=20 >>> The above sort of make.conf is used for port builds, though I may >>> edit the details to control my experiments. >>>=20 >>> The below are tied to buildworld/buildkernel related activity: >>>=20 >>>> # more >>>> = /root/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_cla= ng_xtoolchain-powerpc64-host.sh >>>> script >>>> = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain-powerpc64-host-$(date >>>> +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf"= >>>> = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-= host" >>>> \ MAKEOBJDIRPREFIX=3D"/usr/obj/xtoolchain/powerpc.powerpc64" \ make >>>> $* >>>=20 >>>=20 >>> /root/src.configs/make.conf (used for buildworld/buildkernel) is >>> normally empty. >>>=20 >>>> # more >>>> /root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host=20 >>>> TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3Dpowerpc64=20= >>>> TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D11.0 #=20 >>>> KERNCONF=3DGENERIC64vtsc-NODEBUG TARGET=3Dpowerpc .if = ${.MAKE.LEVEL} =3D=3D >>>> 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif #=20 >>>> WITHOUT_CROSS_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D=20 >>>> #WITH_LIB32=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D=20= >>>> WITH_LLDB=3D # # LIB32 builds but does not work via gcc variants >>>> [crtbeginS code problem(s)] WITHOUT_LIB32=3D WITHOUT_GCC=3D=20 >>>> WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D #=20 >>>> WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # >>>> So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # >>>> TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils. >>>> . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc=20 >>>> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ = .if >>>> ${.MAKE.LEVEL} =3D=3D 0=20 >>>> = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c >>>>=20 >>>>=20 >> = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ >>>> = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp >>>>=20 >>>>=20 >> .export XCC >>>> .export XCXX .export XCPP=20 >>>> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as=20 >>>> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar=20 >>>> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld=20 >>>> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm=20 >>>> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy=20 >>>> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump=20 >>>> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib=20 >>>> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: >>>> XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings=20 >>>> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export >>>> XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export >>>> XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # #=20= >>>> # For FROM (host) stages . . . # =46rom gccXY (such as gcc49 but = not >>>> xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if >>>> ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include >>>> /usr/local/bin/gcc49 -L/usr/lib CXX=3Denv = C_INCLUDE_PATH=3D/usr/include >>>> CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 >>>> -std=3Dc++11 -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp49 = .export >>>> CC .export CXX .export CPP=20 >>>> = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s >>>>=20 >>>>=20 >> = AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= r >>>> = LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l= d >>>>=20 >>>>=20 >> = NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n= m >>>> = OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objcopy >>>>=20 >>>>=20 >> = OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objdump >>>> = RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/ranlib >>>>=20 >>>>=20 >> = SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin= /size >>>> #NO-SUCH: >>>> = STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/strings >>>>=20 >>>>=20 >> STRINGS=3D/usr/local/bin/strings >>>> .export AS .export AR .export LD .export NM .export OBJCOPY .export >>>> OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif >>>=20 >>>> # svnlite status /usr/src ? /usr/src/.snap M >>>> = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>>>=20 >>>>=20 >> M /usr/src/lib/csu/powerpc64/Makefile >>>> ? /usr/src/restoresymtable ? >>>> /usr/src/sys/arm/conf/RPI2-NODBG M >>>> /usr/src/sys/boot/ofw/Makefile.inc M >>>> /usr/src/sys/boot/powerpc/Makefile M >>>> /usr/src/sys/boot/powerpc/Makefile.inc M >>>> /usr/src/sys/boot/uboot/Makefile.inc M >>>> /usr/src/sys/conf/Makefile.powerpc M >>>> /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk ? >>>> /usr/src/sys/powerpc/conf/GENERIC64-NODBG ? >>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc ? >>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? >>>> /usr/src/sys/powerpc/conf/GENERICvtsc ? >>>> /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG M >>>> /usr/src/sys/powerpc/ofw/ofw_machdep.c M >>>> /usr/src/sys/powerpc/powerpc/exec_machdep.c >>>=20 >>>=20 >>=20 >> Let me know what you find. There was some work on external compiler >> support, though I don't know it's current status. >=20 > My powerpc64 FreeBSD activity is completely dependent on the external = compiler support: I'm using FreeBSD's modern libc++, not libstdc++. But = there are some workarounds involved for my complete avoidance of gcc = 4.2.1. I've a few other work arounds for the PowerMac context as well. = For example: downloaded release and snapshot installations do not = reliably boot such PowerMacs but instead frequently hang during boot. = (The frequency may depend on the amount of RAM.) >=20 > I'll let you know how the updated devel/gcc6-devel goes for my style = of powerpc64 environment. >=20 > If a devel/gcc6 appears I'll likely build it at some point. >=20 >> Steve >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-ppc@freebsd.org Sun Apr 24 12:58:40 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3C567B19045; Sun, 24 Apr 2016 12:58:40 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2BDA16E4; Sun, 24 Apr 2016 12:58:39 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id u3OCwPw9073108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Apr 2016 12:58:30 GMT (envelope-from swills@FreeBSD.org) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? To: Mark Millard References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML From: Steve Wills Message-ID: <571CC2F2.2060601@FreeBSD.org> Date: Sun, 24 Apr 2016 08:58:26 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Sun, 24 Apr 2016 12:58:31 +0000 (UTC) X-Spam-Status: No, score=2.8 required=4.5 tests=HELO_MISC_IP, RCVD_ILLEGAL_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 12:58:40 -0000 So lang/gcc6-devel builds fine using gcc49 (which builds fine and isn't currently marked broken. Can we patch the lang/gcc6-devel port so that it uses gcc49 when building on powerpc64? Also, which compiler are you using for building ruby? Steve On 04/24/16 03:19 AM, Mark Millard wrote: > [A top-post of the results of my test build of lang/gcc6-devel using gcc49 to do the build (until it switches over to xgcc). I do not have lang/gcc or lang/gcc48 installed.] > > lang/gcc6-devel's update built fine in my powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a powerpc64 PowerMac. The options were as I normally use: > >> # more /var/db/ports/lang_gcc6-devel/options >> # This file is auto-generated by 'make config'. >> # Options for gcc6-devel-6.0.0.s20160110 >> _OPTIONS_READ=gcc6-devel-6.0.0.s20160110 >> _FILE_COMPLETE_OPTIONS_LIST=BOOTSTRAP GRAPHITE JAVA MULTILIB >> OPTIONS_FILE_UNSET+=BOOTSTRAP >> OPTIONS_FILE_UNSET+=GRAPHITE >> OPTIONS_FILE_UNSET+=JAVA >> OPTIONS_FILE_UNSET+=MULTILIB > > > I will note that ruby is implicitly in use in my environment and it too had been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , and lang/ruby23 all were so marked. (So I commented those marks out.) > > My build that upgraded from ruby21 to ruby22 went fine. > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Apr-23, at 5:21 PM, Mark Millard wrote: >> >> On 2016-Apr-23, at 4:17 PM, Steve Wills wrote: >>> >>> Hi, >>> >>> On 04/23/16 05:50 PM, Mark Millard wrote: >>>> Recently a large block of ports (including lang/gcc6-devel) were >>>> marked in their Makefiles with >>>> >>>>> BROKEN_powerpc64= Does not build >>>> >>>> >>>> Does this only apply for use of gcc/g++ 4.2.1 or specific other >>>> verions? If so that is not the only way to have a powerpc64 >>>> environment. For example: how "official" is use of >>>> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and >>>> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)? >>> >>> >>> The intent was just that they don't build with the default config, ie, >>> gcc 4.2.1 from base. If there are ways to make things build with other >>> compilers, we should look at getting those changes into ports. >>> >>> You can find the logs of the build that I based all those changes on here: >>> >>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default&build=2016-04-02_20h57m16s >>> >>> Specifically the gcc6-devel one is here: >>> >>> http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log >>> >>> Though I realize now that was simply a timeout and perhaps shouldn't >>> have been marked as broken. A few of the llvm ones timed out and I >>> didn't mark those as broken and meant to not mark any that timed out as >>> broken, and to go back and retry them, but didn't notice this one was a >>> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it >>> builds for you. >> >> Since my original note -r413919 has updated devel/gcc6-devel. So I'll end up testing that update once I get to that point. >> >> I'll note that the svn-ports-head entry for -r412746 lists several llvm items: >> >> head/devel/llvm-cheri/Makefile >> head/devel/llvm-devel/Makefile >> head/devel/llvm33/Makefile >> head/devel/llvm34/Makefile >> head/devel/llvm38/Makefile >> >> But I do not build any of those normally. llvm38 likely is toolchain vintage dependent for if it builds or not. Others may be as well. >> >>> Also note that build was using the 2016Q2 branch, but the >>> BROKEN_powerpc64 was committed to the main branch. Perhaps that change >>> should be merged to the 2016Q2 branch. >>> >>> Anyway, I'm currently retrying the build, after fixing pixman and >>> merging that to the 2016Q2 and then locally patching in the >>> BROKEN_powerpc64 things into my local tree. You can see the progress of >>> that here: >>> >>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default&build=2016-04-21_17h38m55s >>> >>> >>>> Can broken be marked for only specific tool chains? >>>> >>> >>> Not trivially, but it's probably doable somehow. >>> >>>>> # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU >>>>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M: >>>>> Sat Apr 9 22:22:19 PDT 2016 >>>>> root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG >>>>> powerpc 1100105 1100105 >>>> >>>> For the rest of this note I'll focus on lang/gcc-devel since I happen >>>> to build and install it. >>>> >>>>> # pkg info '*gcc*' gcc49-4.9.4.s20160406 >>>>> gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0 >>>>> powerpc64-xtoolchain-gcc-0.1 >>>> >>>> gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on the >>>> that same old PowerMac. -r413188 is the prior lang/gcc-devel check in >>>> before being marked broken for powerpc64. For how I build it was not >>>> broken at the time. >>>> >>>> I historically use devel/powerpc64-xtoolchain-gcc (so >>>> devel/powerpc64-gcc as well) for the so-called "cross build" stages >>>> of buildworld/buildkernel (11.0-CURRENT). (I also do true cross >>>> builds for TARGET_ARCH=powerpc64 from an amd64 context sometimes.) >>>> >>>> gcc 4.2.1 is not present before, during, or after on the old >>>> PowerMac. I do build clang and various related materials but do not >>>> use clang for buildworld/buildkernel related activity. I experiment >>>> with using clang for other things at times. >>>> >>>> I historically use lang/gcc49 on the old PowerMac for: >>>> >>>> A) building devel/powerpc64-gcc (not the only way to try to build >>>> it) B) the "host" stages of buildworld/buildkernel (11.0-CURRENT) C) >>>> building lang/gcc6-devel (not the only way to try to build it) >>>> >>>> [I do not have lang/gcc5 built/installed only because it and >>>> devel/powerpc64-gcc have file conflicts when they are based on the >>>> same gcc version. Getting devel/powerpc64-gcc to build and install on >>>> a powerpc64 requires some workarounds because it is not a true cross >>>> compile environment and some file names are odd for self-hosted and >>>> so not found during staging's copy activities.] >>>> >>>> [I do build the system's clang 3.8.0 but do not use it other than for >>>> exploring/checking its current powerpc64 FreeBSD limitations. It does >>>> work for various things but not everything. Those experiments do not >>>> include buildworld or buildkernel. For example: clang 3.8.0 targeting >>>> powerpc64 can not build libstand due to lack of software floating >>>> point support. C++ exception handling built via clang for powerpc64 >>>> is messed up as well.] >>>> >>>> >>> >>> It would be nice if we could fix those things and get powerpc(64) built >>> with clang. >> >> https://llvm.org/bugs/show_bug.cgi?id=25780 [a meta-list of reports that block use by freebsd] lists various powerpc and powerpc64 code-generation issues for clang 3.8.0 vs. FreeBSD. As I remember each of the following includes examples of powerpc64 code-generation issues, not just powerpc (non-64) ones. >> >> https://llvm.org/bugs/show_bug.cgi?id=26970 >> https://llvm.org/bugs/show_bug.cgi?id=26856 >> https://llvm.org/bugs/show_bug.cgi?id=26844 >> https://llvm.org/bugs/show_bug.cgi?id=26761 >> >> (I also submitted reports to freebsd as well so there would be reminders to track clang fixes if they ever occur. There may be more issues than I reported in either place.) >> >> As I remember I thought there were also some FreeBSD problems that would be present after the above were fixed but the code generation problems made it harder to be sure. Even if I was correct any testing based on the bad code-generation by clang in overlapping areas would not work. I'd prefer to recheck/reanalyze based on seeing good code generation results. >> >> Unfortunately while I can slowly analyze/research the code generated it would take a lot longer to get the point of doing non-trival work on llvm or clang itself. And since somewhat after clang 3.8.0 moved into 11.0-CURRENT other things have kept me mostly out of clang investigations. I've just been rebuilding FreeBSD and some ports periodically in order to avoid large jumps later. >> >> >>>> >>>> I have started a powerpc64 self-hosted buildworld/buildkernel for an >>>> update to 11.0-CURRENT -r298518 in preparation for then updating my >>>> ports to -r413907 or so. >>>> >>>> My intent is to comment out the BROKEN_powerpc64 line in >>>> lang/gcc6-devel/Makefile and see if lang/gcc6-devel still (re-)builds >>>> once everything else is up to date. >>>> >>>> But the builds involved take many hours so I'll likely not have a >>>> result to report until tomorrow (or later). >>>> >>>> >>>> Supporting example details: >>>> >>>>> # svnlite info /usr/ports Path: /usr/ports Working Copy Root Path: >>>>> /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head >>>>> Relative URL: ^/head Repository Root: >>>>> https://svn0.us-west.freebsd.org/ports Repository UUID: >>>>> 35697150-7ecd-e111-bb59-0022644237b5 Revision: 413230 Node Kind: >>>>> directory Schedule: normal Last Changed Author: kmoore Last Changed >>>>> Rev: 413230 Last Changed Date: 2016-04-13 13:07:37 -0700 (Wed, 13 >>>>> Apr 2016) >>>> >>>> (I'll svnlite update -r413907 /usr/ports [or there about] after the >>>> system is updated. The above was used for my existing lang/gcc-devel >>>> build on powerpc64 for powerpc64.) >>>> >>>>> # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 >>>>> WRKDIRPREFIX=/usr/obj/portswork WITH_DEBUG= WITH_DEBUG_FILES= >>>>> MALLOC_PRODUCTION= # # # For trying gcc49... # >>>>> CC=/usr/local/bin/gcc49 CXX=/usr/local/bin/g++49 >>>>> CPP=/usr/local/bin/cpp49 # # # For trying port binutils... # >>>>> CROSS_BINUTILS_PREFIX=/usr/local/powerpc64-portbld-freebsd11.0/bin/ >>>>> >>>>> >>> AS=/usr/local/powerpc64-portbld-freebsd11.0/bin/as >>>>> AR=/usr/local/powerpc64-portbld-freebsd11.0/bin/ar >>>>> LD=/usr/local/powerpc64-portbld-freebsd11.0/bin/ld >>>>> NM=/usr/local/powerpc64-portbld-freebsd11.0/bin/nm >>>>> OBJCOPY=/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy >>>>> OBJDUMP=/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump >>>>> RANLIB=/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib >>>>> SIZE=/usr/local/powerpc64-portbld-freebsd11.0/bin/size #NO-SUCH: >>>>> STRINGS=/usr/local/powerpc64-portbld-freebsd11.0/bin/strings >>>>> STRINGS=/usr/local/bin/strings >>>> >>>> The above sort of make.conf is used for port builds, though I may >>>> edit the details to control my experiments. >>>> >>>> The below are tied to buildworld/buildkernel related activity: >>>> >>>>> # more >>>>> /root/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_clang_xtoolchain-powerpc64-host.sh >>>>> script >>>>> /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolchain-powerpc64-host-$(date >>>>> +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF="/root/src.configs/make.conf" >>>>> SRC_ENV_CONF="/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host" >>>>> \ MAKEOBJDIRPREFIX="/usr/obj/xtoolchain/powerpc.powerpc64" \ make >>>>> $* >>>> >>>> >>>> /root/src.configs/make.conf (used for buildworld/buildkernel) is >>>> normally empty. >>>> >>>>> # more >>>>> /root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host >>>>> TO_TYPE=powerpc64 TOOLS_TO_TYPE=${TO_TYPE} FROM_TYPE=powerpc64 >>>>> TOOLS_FROM_TYPE=${FROM_TYPE} VERSION_CONTEXT=11.0 # >>>>> KERNCONF=GENERIC64vtsc-NODEBUG TARGET=powerpc .if ${.MAKE.LEVEL} == >>>>> 0 TARGET_ARCH=${TO_TYPE} .export TARGET_ARCH .endif # >>>>> WITHOUT_CROSS_COMPILER= # WITH_LIBCPLUSPLUS= WITH_BOOT= >>>>> #WITH_LIB32= WITH_CLANG= WITH_CLANG_IS_CC= WITH_CLANG_FULL= >>>>> WITH_LLDB= # # LIB32 builds but does not work via gcc variants >>>>> [crtbeginS code problem(s)] WITHOUT_LIB32= WITHOUT_GCC= >>>>> WITHOUT_GNUCXX= # NO_WERROR= MALLOC_PRODUCTION= # >>>>> WITH_DEBUG_FILES= # # # For TO (so-called "cross") stages . . . # >>>>> So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # >>>>> TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils. >>>>> . . # CROSS_TOOLCHAIN=${TO_TYPE}-gcc X_COMPILER_TYPE=gcc >>>>> CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if >>>>> ${.MAKE.LEVEL} == 0 >>>>> XCC=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gcc >>>>> >>>>> >>> XCXX=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g++ >>>>> XCPP=/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-cpp >>>>> >>>>> >>> .export XCC >>>>> .export XCXX .export XCPP >>>>> XAS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as >>>>> XAR=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar >>>>> XLD=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld >>>>> XNM=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm >>>>> XOBJCOPY=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy >>>>> XOBJDUMP=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump >>>>> XRANLIB=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib >>>>> XSIZE=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: >>>>> XSTRINGS=/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings >>>>> XSTRINGS=/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export >>>>> XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export >>>>> XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # >>>>> # For FROM (host) stages . . . # From gccXY (such as gcc49 but not >>>>> xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if >>>>> ${.MAKE.LEVEL} == 0 CC=env C_INCLUDE_PATH=/usr/include >>>>> /usr/local/bin/gcc49 -L/usr/lib CXX=env C_INCLUDE_PATH=/usr/include >>>>> CPLUS_INCLUDE_PATH=/usr/include/c++/v1 /usr/local/bin/g++49 >>>>> -std=c++11 -nostdinc++ -L/usr/lib CPP=/usr/local/bin/cpp49 .export >>>>> CC .export CXX .export CPP >>>>> AS=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/as >>>>> >>>>> >>> AR=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ar >>>>> LD=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ld >>>>> >>>>> >>> NM=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/nm >>>>> OBJCOPY=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objcopy >>>>> >>>>> >>> OBJDUMP=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objdump >>>>> RANLIB=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ranlib >>>>> >>>>> >>> SIZE=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/size >>>>> #NO-SUCH: >>>>> STRINGS=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/strings >>>>> >>>>> >>> STRINGS=/usr/local/bin/strings >>>>> .export AS .export AR .export LD .export NM .export OBJCOPY .export >>>>> OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif >>>> >>>>> # svnlite status /usr/src ? /usr/src/.snap M >>>>> /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>>>> >>>>> >>> M /usr/src/lib/csu/powerpc64/Makefile >>>>> ? /usr/src/restoresymtable ? >>>>> /usr/src/sys/arm/conf/RPI2-NODBG M >>>>> /usr/src/sys/boot/ofw/Makefile.inc M >>>>> /usr/src/sys/boot/powerpc/Makefile M >>>>> /usr/src/sys/boot/powerpc/Makefile.inc M >>>>> /usr/src/sys/boot/uboot/Makefile.inc M >>>>> /usr/src/sys/conf/Makefile.powerpc M >>>>> /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk ? >>>>> /usr/src/sys/powerpc/conf/GENERIC64-NODBG ? >>>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc ? >>>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? >>>>> /usr/src/sys/powerpc/conf/GENERICvtsc ? >>>>> /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG M >>>>> /usr/src/sys/powerpc/ofw/ofw_machdep.c M >>>>> /usr/src/sys/powerpc/powerpc/exec_machdep.c >>>> >>>> >>> >>> Let me know what you find. There was some work on external compiler >>> support, though I don't know it's current status. >> >> My powerpc64 FreeBSD activity is completely dependent on the external compiler support: I'm using FreeBSD's modern libc++, not libstdc++. But there are some workarounds involved for my complete avoidance of gcc 4.2.1. I've a few other work arounds for the PowerMac context as well. For example: downloaded release and snapshot installations do not reliably boot such PowerMacs but instead frequently hang during boot. (The frequency may depend on the amount of RAM.) >> >> I'll let you know how the updated devel/gcc6-devel goes for my style of powerpc64 environment. >> >> If a devel/gcc6 appears I'll likely build it at some point. >> >>> Steve >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" > From owner-freebsd-ppc@freebsd.org Sun Apr 24 14:16:10 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A97FB1A26C for ; Sun, 24 Apr 2016 14:16:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-158.reflexion.net [208.70.211.158]) (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 10B451DAD for ; Sun, 24 Apr 2016 14:16:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21466 invoked from network); 24 Apr 2016 14:16:33 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Apr 2016 14:16:33 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sun, 24 Apr 2016 10:16:36 -0400 (EDT) Received: (qmail 27178 invoked from network); 24 Apr 2016 14:16:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 Apr 2016 14:16:36 -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-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0F9511C4388; Sun, 24 Apr 2016 07:16:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? From: Mark Millard In-Reply-To: <571CC2F2.2060601@FreeBSD.org> Date: Sun, 24 Apr 2016 07:16:06 -0700 Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> To: Steve Wills X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 14:16:10 -0000 On 2016-Apr-24, at 5:58 AM, Steve Wills wrote: >=20 > So lang/gcc6-devel builds fine using gcc49 (which builds fine and = isn't > currently marked broken. Can we patch the lang/gcc6-devel port so that > it uses gcc49 when building on powerpc64? >=20 > Also, which compiler are you using for building ruby? >=20 > Steve For all the port update activity (including ruby) I used gcc49, = /etc/make.conf being: # more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20 WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D=20 MALLOC_PRODUCTION=3D # # # For trying gcc49... #=20 CC=3D/usr/local/bin/gcc49 CXX=3D/usr/local/bin/g++49=20 CPP=3D/usr/local/bin/cpp49 . . . (binutils macros omitted here) . . . (I do not know if lang/gcc [or lang/gcc48] would work or not. I prefer a = tool chain with a more modern C++ available but gcc49 is not yet what = lang/gcc builds.) I've seen notation like: USE_GCC=3D 4.9+ in port Makefiles. Also notation like: .if ${ARCH} =3D=3D powerpc64 and: .if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64" So may be the extra notation in the Makefile(s) in question could be = something like: # clang 3.8.0 and before is still broken in various ways for powerpc and = powerpc64: .if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64" USE_GCC=3D 4.9+ .endif I list both powerpc variants because powerpc and powerpc64 both have = clang problems making buildworld a no-go by default and if gcc 4.2.1 = rejects a port for one it would normally also reject for the other. = There may be other ${ARCH} values that would also be appropriate because = they are also stuck at gcc 4.2.1 . I do not claim to know necessary vs. sufficient status: more might be = needed for some configurations (rpath issues? mixture of libraries = compiled by distinct gcc's?). But I expect that the above should be = better than being marked broken. =3D=3D=3D Mark Millard markmi at dsl-only.net Older material: On 04/24/16 03:19 AM, Mark Millard wrote: > [A top-post of the results of my test build of lang/gcc6-devel using = gcc49 to do the build (until it switches over to xgcc). I do not have = lang/gcc or lang/gcc48 installed.] >=20 > lang/gcc6-devel's update built fine in my = powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a = powerpc64 PowerMac. The options were as I normally use: >=20 >> # more /var/db/ports/lang_gcc6-devel/options >> # This file is auto-generated by 'make config'. >> # Options for gcc6-devel-6.0.0.s20160110 >> _OPTIONS_READ=3Dgcc6-devel-6.0.0.s20160110 >> _FILE_COMPLETE_OPTIONS_LIST=3DBOOTSTRAP GRAPHITE JAVA MULTILIB >> OPTIONS_FILE_UNSET+=3DBOOTSTRAP >> OPTIONS_FILE_UNSET+=3DGRAPHITE >> OPTIONS_FILE_UNSET+=3DJAVA >> OPTIONS_FILE_UNSET+=3DMULTILIB >=20 >=20 > I will note that ruby is implicitly in use in my environment and it = too had been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , = and lang/ruby23 all were so marked. (So I commented those marks out.) >=20 > My build that upgraded from ruby21 to ruby22 went fine. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Apr-23, at 5:21 PM, Mark Millard wrote: >>=20 >> On 2016-Apr-23, at 4:17 PM, Steve Wills wrote: >>>=20 >>> Hi, >>>=20 >>> On 04/23/16 05:50 PM, Mark Millard wrote: >>>> Recently a large block of ports (including lang/gcc6-devel) were >>>> marked in their Makefiles with >>>>=20 >>>>> BROKEN_powerpc64=3D Does not build >>>>=20 >>>>=20 >>>> Does this only apply for use of gcc/g++ 4.2.1 or specific other >>>> verions? If so that is not the only way to have a powerpc64 >>>> environment. For example: how "official" is use of >>>> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and >>>> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)?=20 >>>=20 >>>=20 >>> The intent was just that they don't build with the default config, = ie, >>> gcc 4.2.1 from base. If there are ways to make things build with = other >>> compilers, we should look at getting those changes into ports. >>>=20 >>> You can find the logs of the build that I based all those changes on = here: >>>=20 >>> = http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower= pc-default&build=3D2016-04-02_20h57m16s >>>=20 >>> Specifically the gcc6-devel one is here: >>>=20 >>> = http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-= 02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log >>>=20 >>> Though I realize now that was simply a timeout and perhaps shouldn't >>> have been marked as broken. A few of the llvm ones timed out and I >>> didn't mark those as broken and meant to not mark any that timed out = as >>> broken, and to go back and retry them, but didn't notice this one = was a >>> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if = it >>> builds for you. >>=20 >> Since my original note -r413919 has updated devel/gcc6-devel. So I'll = end up testing that update once I get to that point. >>=20 >> I'll note that the svn-ports-head entry for -r412746 lists several = llvm items: >>=20 >> head/devel/llvm-cheri/Makefile >> head/devel/llvm-devel/Makefile >> head/devel/llvm33/Makefile >> head/devel/llvm34/Makefile >> head/devel/llvm38/Makefile >>=20 >> But I do not build any of those normally. llvm38 likely is toolchain = vintage dependent for if it builds or not. Others may be as well. >>=20 >>> Also note that build was using the 2016Q2 branch, but the >>> BROKEN_powerpc64 was committed to the main branch. Perhaps that = change >>> should be merged to the 2016Q2 branch. >>>=20 >>> Anyway, I'm currently retrying the build, after fixing pixman and >>> merging that to the 2016Q2 and then locally patching in the >>> BROKEN_powerpc64 things into my local tree. You can see the progress = of >>> that here: >>>=20 >>> = http://poudriere.mouf.net/karl/poudriere/build.html?mastername=3Dheadpower= pc-default&build=3D2016-04-21_17h38m55s >>>=20 >>>=20 >>>> Can broken be marked for only specific tool chains? >>>>=20 >>>=20 >>> Not trivially, but it's probably doable somehow. >>>=20 >>>>> # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU=20 >>>>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M: >>>>> Sat Apr 9 22:22:19 PDT 2016 >>>>> = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG >>>>> powerpc 1100105 1100105 >>>>=20 >>>> For the rest of this note I'll focus on lang/gcc-devel since I = happen >>>> to build and install it. >>>>=20 >>>>> # pkg info '*gcc*' gcc49-4.9.4.s20160406=20 >>>>> gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0=20 >>>>> powerpc64-xtoolchain-gcc-0.1 >>>>=20 >>>> gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on = the >>>> that same old PowerMac. -r413188 is the prior lang/gcc-devel check = in >>>> before being marked broken for powerpc64. For how I build it was = not >>>> broken at the time. >>>>=20 >>>> I historically use devel/powerpc64-xtoolchain-gcc (so >>>> devel/powerpc64-gcc as well) for the so-called "cross build" stages >>>> of buildworld/buildkernel (11.0-CURRENT). (I also do true cross >>>> builds for TARGET_ARCH=3Dpowerpc64 from an amd64 context = sometimes.) >>>>=20 >>>> gcc 4.2.1 is not present before, during, or after on the old >>>> PowerMac. I do build clang and various related materials but do not >>>> use clang for buildworld/buildkernel related activity. I experiment >>>> with using clang for other things at times. >>>>=20 >>>> I historically use lang/gcc49 on the old PowerMac for: >>>>=20 >>>> A) building devel/powerpc64-gcc (not the only way to try to build >>>> it) B) the "host" stages of buildworld/buildkernel (11.0-CURRENT) = C) >>>> building lang/gcc6-devel (not the only way to try to build it) >>>>=20 >>>> [I do not have lang/gcc5 built/installed only because it and >>>> devel/powerpc64-gcc have file conflicts when they are based on the >>>> same gcc version. Getting devel/powerpc64-gcc to build and install = on >>>> a powerpc64 requires some workarounds because it is not a true = cross >>>> compile environment and some file names are odd for self-hosted and >>>> so not found during staging's copy activities.] >>>>=20 >>>> [I do build the system's clang 3.8.0 but do not use it other than = for >>>> exploring/checking its current powerpc64 FreeBSD limitations. It = does >>>> work for various things but not everything. Those experiments do = not >>>> include buildworld or buildkernel. For example: clang 3.8.0 = targeting >>>> powerpc64 can not build libstand due to lack of software floating >>>> point support. C++ exception handling built via clang for powerpc64 >>>> is messed up as well.] >>>>=20 >>>>=20 >>>=20 >>> It would be nice if we could fix those things and get powerpc(64) = built >>> with clang. >>=20 >> https://llvm.org/bugs/show_bug.cgi?id=3D25780 [a meta-list of reports = that block use by freebsd] lists various powerpc and powerpc64 = code-generation issues for clang 3.8.0 vs. FreeBSD. As I remember each = of the following includes examples of powerpc64 code-generation issues, = not just powerpc (non-64) ones. >>=20 >> https://llvm.org/bugs/show_bug.cgi?id=3D26970 >> https://llvm.org/bugs/show_bug.cgi?id=3D26856 >> https://llvm.org/bugs/show_bug.cgi?id=3D26844 >> https://llvm.org/bugs/show_bug.cgi?id=3D26761 >>=20 >> (I also submitted reports to freebsd as well so there would be = reminders to track clang fixes if they ever occur. There may be more = issues than I reported in either place.) >>=20 >> As I remember I thought there were also some FreeBSD problems that = would be present after the above were fixed but the code generation = problems made it harder to be sure. Even if I was correct any testing = based on the bad code-generation by clang in overlapping areas would not = work. I'd prefer to recheck/reanalyze based on seeing good code = generation results. >>=20 >> Unfortunately while I can slowly analyze/research the code generated = it would take a lot longer to get the point of doing non-trival work on = llvm or clang itself. And since somewhat after clang 3.8.0 moved into = 11.0-CURRENT other things have kept me mostly out of clang = investigations. I've just been rebuilding FreeBSD and some ports = periodically in order to avoid large jumps later. >>=20 >>=20 >>>>=20 >>>> I have started a powerpc64 self-hosted buildworld/buildkernel for = an >>>> update to 11.0-CURRENT -r298518 in preparation for then updating my >>>> ports to -r413907 or so. >>>>=20 >>>> My intent is to comment out the BROKEN_powerpc64 line in >>>> lang/gcc6-devel/Makefile and see if lang/gcc6-devel still = (re-)builds >>>> once everything else is up to date. >>>>=20 >>>> But the builds involved take many hours so I'll likely not have a >>>> result to report until tomorrow (or later). >>>>=20 >>>>=20 >>>> Supporting example details: >>>>=20 >>>>> # svnlite info /usr/ports Path: /usr/ports Working Copy Root Path: >>>>> /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head=20 >>>>> Relative URL: ^/head Repository Root: >>>>> https://svn0.us-west.freebsd.org/ports Repository UUID: >>>>> 35697150-7ecd-e111-bb59-0022644237b5 Revision: 413230 Node Kind: >>>>> directory Schedule: normal Last Changed Author: kmoore Last = Changed >>>>> Rev: 413230 Last Changed Date: 2016-04-13 13:07:37 -0700 (Wed, 13 >>>>> Apr 2016) >>>>=20 >>>> (I'll svnlite update -r413907 /usr/ports [or there about] after the >>>> system is updated. The above was used for my existing = lang/gcc-devel >>>> build on powerpc64 for powerpc64.) >>>>=20 >>>>> # more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20 >>>>> WRKDIRPREFIX=3D/usr/obj/portswork WITH_DEBUG=3D WITH_DEBUG_FILES=3D=20= >>>>> MALLOC_PRODUCTION=3D # # # For trying gcc49... #=20 >>>>> CC=3D/usr/local/bin/gcc49 CXX=3D/usr/local/bin/g++49=20 >>>>> CPP=3D/usr/local/bin/cpp49 # # # For trying port binutils... #=20 >>>>> = CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ >>>>>=20 >>>>>=20 >>> AS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/as >>>>> AR=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ar=20 >>>>> LD=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ld=20 >>>>> NM=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/nm=20 >>>>> OBJCOPY=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objcopy=20 >>>>> OBJDUMP=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/objdump=20 >>>>> RANLIB=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/ranlib=20 >>>>> SIZE=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/size #NO-SUCH: >>>>> STRINGS=3D/usr/local/powerpc64-portbld-freebsd11.0/bin/strings=20 >>>>> STRINGS=3D/usr/local/bin/strings >>>>=20 >>>> The above sort of make.conf is used for port builds, though I may >>>> edit the details to control my experiments. >>>>=20 >>>> The below are tied to buildworld/buildkernel related activity: >>>>=20 >>>>> # more >>>>> = /root/sys_build_scripts.powerpc64-host/make_powerpc64vtsc_nodebug_incl_cla= ng_xtoolchain-powerpc64-host.sh >>>>> script >>>>> = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xto= olchain-powerpc64-host-$(date >>>>> +%Y-%m-%d:%H:%M:%S) \ env = __MAKE_CONF=3D"/root/src.configs/make.conf" >>>>> = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-= host" >>>>> \ MAKEOBJDIRPREFIX=3D"/usr/obj/xtoolchain/powerpc.powerpc64" \ = make >>>>> $* >>>>=20 >>>>=20 >>>> /root/src.configs/make.conf (used for buildworld/buildkernel) is >>>> normally empty. >>>>=20 >>>>> # more >>>>> /root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host=20 >>>>> TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3Dpowerpc64= =20 >>>>> TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D11.0 #=20 >>>>> KERNCONF=3DGENERIC64vtsc-NODEBUG TARGET=3Dpowerpc .if = ${.MAKE.LEVEL} =3D=3D >>>>> 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif #=20 >>>>> WITHOUT_CROSS_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D=20 >>>>> #WITH_LIB32=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D=20= >>>>> WITH_LLDB=3D # # LIB32 builds but does not work via gcc variants >>>>> [crtbeginS code problem(s)] WITHOUT_LIB32=3D WITHOUT_GCC=3D=20 >>>>> WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D #=20 >>>>> WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . = # >>>>> So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . = # >>>>> TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils. >>>>> . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc=20 >>>>> CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ = .if >>>>> ${.MAKE.LEVEL} =3D=3D 0=20 >>>>> = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c >>>>>=20 >>>>>=20 >>> = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ >>>>> = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp >>>>>=20 >>>>>=20 >>> .export XCC >>>>> .export XCXX .export XCPP=20 >>>>> XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as=20 >>>>> XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar=20 >>>>> XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld=20 >>>>> XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm=20 >>>>> XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy=20 >>>>> XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump=20 >>>>> XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib=20 >>>>> XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: >>>>> XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings=20 >>>>> XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export >>>>> XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export >>>>> XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # #=20= >>>>> # For FROM (host) stages . . . # =46rom gccXY (such as gcc49 but = not >>>>> xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if >>>>> ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include >>>>> /usr/local/bin/gcc49 -L/usr/lib CXX=3Denv = C_INCLUDE_PATH=3D/usr/include >>>>> CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 >>>>> -std=3Dc++11 -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp49 = .export >>>>> CC .export CXX .export CPP=20 >>>>> = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s >>>>>=20 >>>>>=20 >>> = AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= r >>>>> = LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l= d >>>>>=20 >>>>>=20 >>> = NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n= m >>>>> = OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objcopy >>>>>=20 >>>>>=20 >>> = OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objdump >>>>> = RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/ranlib >>>>>=20 >>>>>=20 >>> = SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin= /size >>>>> #NO-SUCH: >>>>> = STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/strings >>>>>=20 >>>>>=20 >>> STRINGS=3D/usr/local/bin/strings >>>>> .export AS .export AR .export LD .export NM .export OBJCOPY = .export >>>>> OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif >>>>=20 >>>>> # svnlite status /usr/src ? /usr/src/.snap M >>>>> = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>>>>=20 >>>>>=20 >>> M /usr/src/lib/csu/powerpc64/Makefile >>>>> ? /usr/src/restoresymtable ? >>>>> /usr/src/sys/arm/conf/RPI2-NODBG M >>>>> /usr/src/sys/boot/ofw/Makefile.inc M >>>>> /usr/src/sys/boot/powerpc/Makefile M >>>>> /usr/src/sys/boot/powerpc/Makefile.inc M >>>>> /usr/src/sys/boot/uboot/Makefile.inc M >>>>> /usr/src/sys/conf/Makefile.powerpc M >>>>> /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk ? >>>>> /usr/src/sys/powerpc/conf/GENERIC64-NODBG ? >>>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc ? >>>>> /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? >>>>> /usr/src/sys/powerpc/conf/GENERICvtsc ? >>>>> /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG M >>>>> /usr/src/sys/powerpc/ofw/ofw_machdep.c M >>>>> /usr/src/sys/powerpc/powerpc/exec_machdep.c >>>>=20 >>>>=20 >>>=20 >>> Let me know what you find. There was some work on external compiler >>> support, though I don't know it's current status. >>=20 >> My powerpc64 FreeBSD activity is completely dependent on the external = compiler support: I'm using FreeBSD's modern libc++, not libstdc++. But = there are some workarounds involved for my complete avoidance of gcc = 4.2.1. I've a few other work arounds for the PowerMac context as well. = For example: downloaded release and snapshot installations do not = reliably boot such PowerMacs but instead frequently hang during boot. = (The frequency may depend on the amount of RAM.) >>=20 >> I'll let you know how the updated devel/gcc6-devel goes for my style = of powerpc64 environment. >>=20 >> If a devel/gcc6 appears I'll likely build it at some point. >>=20 >>> Steve >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >>=20 > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to = "freebsd-ports-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@freebsd.org Sun Apr 24 17:24:33 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55BDBB1B206; Sun, 24 Apr 2016 17:24:33 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 05B661B45; Sun, 24 Apr 2016 17:24:32 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id u3OHOM1i076058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Apr 2016 17:24:27 GMT (envelope-from swills@FreeBSD.org) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? To: Mark Millard References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> Cc: freebsd-ports@freebsd.org, FreeBSD PowerPC ML From: Steve Wills Message-ID: <571D0146.5060200@FreeBSD.org> Date: Sun, 24 Apr 2016 13:24:22 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Sun, 24 Apr 2016 17:24:28 +0000 (UTC) X-Spam-Status: No, score=2.8 required=4.5 tests=HELO_MISC_IP, RCVD_ILLEGAL_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2016 17:24:33 -0000 Hi, On 04/24/16 10:16 AM, Mark Millard wrote: > > For all the port update activity (including ruby) I used gcc49, /etc/make.conf being: > > # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 > WRKDIRPREFIX=/usr/obj/portswork > WITH_DEBUG= > WITH_DEBUG_FILES= > MALLOC_PRODUCTION= > # > # > # For trying gcc49... > # > CC=/usr/local/bin/gcc49 > CXX=/usr/local/bin/g++49 > CPP=/usr/local/bin/cpp49 > . . . (binutils macros omitted here) . . . > > > (I do not know if lang/gcc [or lang/gcc48] would work or not. I > prefer a tool chain with a more modern C++ available but gcc49 is not > yet what lang/gcc builds.) > > > > I've seen notation like: > > USE_GCC= 4.9+ > > in port Makefiles. Also notation like: > > .if ${ARCH} == powerpc64 > > and: > > .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64" > > > So may be the extra notation in the Makefile(s) in question could be something like: > > # clang 3.8.0 and before is still broken in various ways for powerpc and powerpc64: > .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64" > USE_GCC= 4.9+ > .endif > Yep, this sounds right to me. I will test this with at least lang/ruby22 and lang/gcc6-devel when my current build finishes, or sooner if I get impatient. :) > I list both powerpc variants because powerpc and powerpc64 both have > clang problems making buildworld a no-go by default and if gcc 4.2.1 > rejects a port for one it would normally also reject for the other. > There may be other ${ARCH} values that would also be appropriate > because they are also stuck at gcc 4.2.1 . Makes sense. > I do not claim to know necessary vs. sufficient status: more might be > needed for some configurations (rpath issues? mixture of libraries > compiled by distinct gcc's?). But I expect that the above should be > better than being marked broken. We'll find this out when we test! :) Thanks, Steve From owner-freebsd-ppc@freebsd.org Thu Apr 28 13:58:31 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C2A6B1F863 for ; Thu, 28 Apr 2016 13:58:31 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2DA021717 for ; Thu, 28 Apr 2016 13:58:31 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id u3SDwKp7025769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Apr 2016 13:58:26 GMT (envelope-from swills@FreeBSD.org) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? To: Mark Millard References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> <571D0146.5060200@FreeBSD.org> Cc: FreeBSD PowerPC ML From: Steve Wills Message-ID: <572216FD.9030700@FreeBSD.org> Date: Thu, 28 Apr 2016 09:58:21 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <571D0146.5060200@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Thu, 28 Apr 2016 13:58:27 +0000 (UTC) X-Spam-Status: No, score=2.8 required=4.5 tests=HELO_MISC_IP, RCVD_ILLEGAL_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 13:58:31 -0000 I did test this, but it failed. The log is here: http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-27_12h19m39s/logs/gcc6-devel-6.0.0.s20160320.log Looks like gfortran failed to build? Steve On 04/24/16 01:24 PM, Steve Wills wrote: > Hi, > > On 04/24/16 10:16 AM, Mark Millard wrote: >> >> For all the port update activity (including ruby) I used gcc49, /etc/make.conf being: >> >> # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 >> WRKDIRPREFIX=/usr/obj/portswork >> WITH_DEBUG= >> WITH_DEBUG_FILES= >> MALLOC_PRODUCTION= >> # >> # >> # For trying gcc49... >> # >> CC=/usr/local/bin/gcc49 >> CXX=/usr/local/bin/g++49 >> CPP=/usr/local/bin/cpp49 >> . . . (binutils macros omitted here) . . . >> >> >> (I do not know if lang/gcc [or lang/gcc48] would work or not. I >> prefer a tool chain with a more modern C++ available but gcc49 is not >> yet what lang/gcc builds.) >> >> >> >> I've seen notation like: >> >> USE_GCC= 4.9+ >> >> in port Makefiles. Also notation like: >> >> .if ${ARCH} == powerpc64 >> >> and: >> >> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64" >> >> >> So may be the extra notation in the Makefile(s) in question could be something like: >> >> # clang 3.8.0 and before is still broken in various ways for powerpc and powerpc64: >> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64" >> USE_GCC= 4.9+ >> .endif >> > > Yep, this sounds right to me. I will test this with at least lang/ruby22 > and lang/gcc6-devel when my current build finishes, or sooner if I get > impatient. :) > > >> I list both powerpc variants because powerpc and powerpc64 both have >> clang problems making buildworld a no-go by default and if gcc 4.2.1 >> rejects a port for one it would normally also reject for the other. >> There may be other ${ARCH} values that would also be appropriate >> because they are also stuck at gcc 4.2.1 . > > Makes sense. > >> I do not claim to know necessary vs. sufficient status: more might be >> needed for some configurations (rpath issues? mixture of libraries >> compiled by distinct gcc's?). But I expect that the above should be >> better than being marked broken. > > We'll find this out when we test! :) > > Thanks, > Steve > From owner-freebsd-ppc@freebsd.org Thu Apr 28 17:19:55 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 13058B1F88B for ; Thu, 28 Apr 2016 17:19:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 BA64111B7 for ; Thu, 28 Apr 2016 17:19:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4747 invoked from network); 28 Apr 2016 17:13:38 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Apr 2016 17:13:38 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 28 Apr 2016 13:13:11 -0400 (EDT) Received: (qmail 19942 invoked from network); 28 Apr 2016 17:13:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Apr 2016 17:13:11 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8F3ED1C43D2; Thu, 28 Apr 2016 10:13:08 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? From: Mark Millard In-Reply-To: <572216FD.9030700@FreeBSD.org> Date: Thu, 28 Apr 2016 10:13:11 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1ABC33D7-86DB-4CA7-BA48-A995AB6DEA7C@dsl-only.net> References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> <571D0146.5060200@FreeBSD.org> <572216FD.9030700@FreeBSD.org> To: Steve Wills X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:19:55 -0000 On 2016-Apr-28, at 6:58 AM, Steve Wills wrote: >=20 > I did test this, but it failed. The log is here: >=20 > = http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-= 27_12h19m39s/logs/gcc6-devel-6.0.0.s20160320.log >=20 > Looks like gfortran failed to build? >=20 > Steve The file name gcc6-devel-6.0.0.s20160320.log indicates the s20160320 = version but I used /usr/ports -r413919 which built: > # pkg info 'gcc6*' > gcc6-devel-6.0.1.s20160421 In other words: about a month later for the gcc6 version. I do not know if this makes a difference or not. poudriere.mouf.net is not responding currently: > The server is temporarily unable to service your request due to = maintenance downtime or capacity problems. Please try again later =3D=3D=3D Mark Millard markmi at dsl-only.net On 04/24/16 01:24 PM, Steve Wills wrote: > Hi, >=20 > On 04/24/16 10:16 AM, Mark Millard wrote: >>=20 >> For all the port update activity (including ruby) I used gcc49, = /etc/make.conf being: >>=20 >> # more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20 >> WRKDIRPREFIX=3D/usr/obj/portswork >> WITH_DEBUG=3D >> WITH_DEBUG_FILES=3D=20 >> MALLOC_PRODUCTION=3D >> # >> # >> # For trying gcc49... >> #=20 >> CC=3D/usr/local/bin/gcc49 >> CXX=3D/usr/local/bin/g++49=20 >> CPP=3D/usr/local/bin/cpp49 >> . . . (binutils macros omitted here) . . . >>=20 >>=20 >> (I do not know if lang/gcc [or lang/gcc48] would work or not. I >> prefer a tool chain with a more modern C++ available but gcc49 is not >> yet what lang/gcc builds.) >>=20 >>=20 >>=20 >> I've seen notation like: >>=20 >> USE_GCC=3D 4.9+ >>=20 >> in port Makefiles. Also notation like: >>=20 >> .if ${ARCH} =3D=3D powerpc64 >>=20 >> and: >>=20 >> .if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64" >>=20 >>=20 >> So may be the extra notation in the Makefile(s) in question could be = something like: >>=20 >> # clang 3.8.0 and before is still broken in various ways for powerpc = and powerpc64: >> .if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64" >> USE_GCC=3D 4.9+ >> .endif >>=20 >=20 > Yep, this sounds right to me. I will test this with at least = lang/ruby22 > and lang/gcc6-devel when my current build finishes, or sooner if I get > impatient. :) >=20 >=20 >> I list both powerpc variants because powerpc and powerpc64 both have >> clang problems making buildworld a no-go by default and if gcc 4.2.1 >> rejects a port for one it would normally also reject for the other. >> There may be other ${ARCH} values that would also be appropriate >> because they are also stuck at gcc 4.2.1 . >=20 > Makes sense. >=20 >> I do not claim to know necessary vs. sufficient status: more might be >> needed for some configurations (rpath issues? mixture of libraries >> compiled by distinct gcc's?). But I expect that the above should be >> better than being marked broken. >=20 > We'll find this out when we test! :) >=20 > Thanks, > Steve >=20 From owner-freebsd-ppc@freebsd.org Thu Apr 28 17:52:54 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1BE55B1F180 for ; Thu, 28 Apr 2016 17:52:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 BAC231762 for ; Thu, 28 Apr 2016 17:52:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29299 invoked from network); 28 Apr 2016 17:53:17 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Apr 2016 17:53:17 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 28 Apr 2016 13:52:50 -0400 (EDT) Received: (qmail 15924 invoked from network); 28 Apr 2016 17:52:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Apr 2016 17:52:50 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BF10B1C4061; Thu, 28 Apr 2016 10:52:47 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? From: Mark Millard In-Reply-To: <1ABC33D7-86DB-4CA7-BA48-A995AB6DEA7C@dsl-only.net> Date: Thu, 28 Apr 2016 10:52:49 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <423516E1-02AA-49DE-AE30-6DF7418C50C4@dsl-only.net> References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> <571D0146.5060200@FreeBSD.org> <572216FD.9030700@FreeBSD.org> <1ABC33D7-86DB-4CA7-BA48-A995AB6DEA7C@dsl-only.net> To: Steve Wills X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 17:52:54 -0000 On 2016-Apr-28, at 10:13 AM, Mark Millard wrote: > On 2016-Apr-28, at 6:58 AM, Steve Wills wrote: >>=20 >> I did test this, but it failed. The log is here: >>=20 >> = http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-= 27_12h19m39s/logs/gcc6-devel-6.0.0.s20160320.log >>=20 >> Looks like gfortran failed to build? >>=20 >> Steve >=20 > The file name gcc6-devel-6.0.0.s20160320.log indicates the s20160320 = version but I used /usr/ports -r413919 which built: >=20 >> # pkg info 'gcc6*' >> gcc6-devel-6.0.1.s20160421 >=20 > In other words: about a month later for the gcc6 version. >=20 > I do not know if this makes a difference or not. >=20 > poudriere.mouf.net is not responding currently: >=20 >> The server is temporarily unable to service your request due to = maintenance downtime or capacity problems. Please try again later >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net Just FYI in case gcc49 is also of a different vintage vs. what I used: > # pkg info 'gcc*' > gcc49-4.9.4.s20160406 > gcc6-devel-6.0.1.s20160421 (I still have no access to the log file via the URL.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 04/24/16 01:24 PM, Steve Wills wrote: > Hi, >=20 > On 04/24/16 10:16 AM, Mark Millard wrote: >>=20 >> For all the port update activity (including ruby) I used gcc49, = /etc/make.conf being: >>=20 >> # more /etc/make.conf DEFAULT_VERSIONS+=3Dperl5=3D5.22=20 >> WRKDIRPREFIX=3D/usr/obj/portswork >> WITH_DEBUG=3D >> WITH_DEBUG_FILES=3D=20 >> MALLOC_PRODUCTION=3D >> # >> # >> # For trying gcc49... >> #=20 >> CC=3D/usr/local/bin/gcc49 >> CXX=3D/usr/local/bin/g++49=20 >> CPP=3D/usr/local/bin/cpp49 >> . . . (binutils macros omitted here) . . . >>=20 >>=20 >> (I do not know if lang/gcc [or lang/gcc48] would work or not. I >> prefer a tool chain with a more modern C++ available but gcc49 is not >> yet what lang/gcc builds.) >>=20 >>=20 >>=20 >> I've seen notation like: >>=20 >> USE_GCC=3D 4.9+ >>=20 >> in port Makefiles. Also notation like: >>=20 >> .if ${ARCH} =3D=3D powerpc64 >>=20 >> and: >>=20 >> .if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64" >>=20 >>=20 >> So may be the extra notation in the Makefile(s) in question could be = something like: >>=20 >> # clang 3.8.0 and before is still broken in various ways for powerpc = and powerpc64: >> .if ${ARCH} =3D=3D "powerpc" || ${ARCH} =3D=3D "powerpc64" >> USE_GCC=3D 4.9+ >> .endif >>=20 >=20 > Yep, this sounds right to me. I will test this with at least = lang/ruby22 > and lang/gcc6-devel when my current build finishes, or sooner if I get > impatient. :) >=20 >=20 >> I list both powerpc variants because powerpc and powerpc64 both have >> clang problems making buildworld a no-go by default and if gcc 4.2.1 >> rejects a port for one it would normally also reject for the other. >> There may be other ${ARCH} values that would also be appropriate >> because they are also stuck at gcc 4.2.1 . >=20 > Makes sense. >=20 >> I do not claim to know necessary vs. sufficient status: more might be >> needed for some configurations (rpath issues? mixture of libraries >> compiled by distinct gcc's?). But I expect that the above should be >> better than being marked broken. >=20 > We'll find this out when we test! :) >=20 > Thanks, > Steve >=20 From owner-freebsd-ppc@freebsd.org Thu Apr 28 20:42:49 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 97055B1FA6C for ; Thu, 28 Apr 2016 20:42:49 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 45EC71973 for ; Thu, 28 Apr 2016 20:42:49 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id u3SKgFUh032566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Apr 2016 20:42:31 GMT (envelope-from swills@FreeBSD.org) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? To: Mark Millard References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> <571D0146.5060200@FreeBSD.org> <572216FD.9030700@FreeBSD.org> <1ABC33D7-86DB-4CA7-BA48-A995AB6DEA7C@dsl-only.net> Cc: FreeBSD PowerPC ML From: Steve Wills Message-ID: <572275A6.2070702@FreeBSD.org> Date: Thu, 28 Apr 2016 16:42:14 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1ABC33D7-86DB-4CA7-BA48-A995AB6DEA7C@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Thu, 28 Apr 2016 20:42:34 +0000 (UTC) X-Spam-Status: No, score=2.8 required=4.5 tests=HELO_MISC_IP, RCVD_ILLEGAL_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 20:42:49 -0000 Hi, On 04/28/16 01:13 PM, Mark Millard wrote: > > On 2016-Apr-28, at 6:58 AM, Steve Wills wrote: >> >> I did test this, but it failed. The log is here: >> >> http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-27_12h19m39s/logs/gcc6-devel-6.0.0.s20160320.log >> >> Looks like gfortran failed to build? >> >> Steve > > The file name gcc6-devel-6.0.0.s20160320.log indicates the s20160320 version but I used /usr/ports -r413919 which built: > >> # pkg info 'gcc6*' >> gcc6-devel-6.0.1.s20160421 > > In other words: about a month later for the gcc6 version. > > I do not know if this makes a difference or not. > I'm building quarterly branch at the moment, but I can update that port locally in my tree and test again. > poudriere.mouf.net is not responding currently: > >> The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later > > Yeah, it's panic'd at the moment, and seems to be doing that whenever deleting jails now, I'll look into that. Last month's update was stable... I'll fix it when I get home. Steve From owner-freebsd-ppc@freebsd.org Thu Apr 28 21:30:40 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C94C1B20466 for ; Thu, 28 Apr 2016 21:30:40 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 847531F9C for ; Thu, 28 Apr 2016 21:30:40 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id u3SLUVC0033280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 Apr 2016 21:30:37 GMT (envelope-from swills@FreeBSD.org) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? To: Mark Millard References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> <571D0146.5060200@FreeBSD.org> <572216FD.9030700@FreeBSD.org> <1ABC33D7-86DB-4CA7-BA48-A995AB6DEA7C@dsl-only.net> <423516E1-02AA-49DE-AE30-6DF7418C50C4@dsl-only.net> Cc: FreeBSD PowerPC ML From: Steve Wills Message-ID: <572280F5.7020202@FreeBSD.org> Date: Thu, 28 Apr 2016 17:30:29 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <423516E1-02AA-49DE-AE30-6DF7418C50C4@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Thu, 28 Apr 2016 21:30:37 +0000 (UTC) X-Spam-Status: No, score=2.8 required=4.5 tests=HELO_MISC_IP, RCVD_ILLEGAL_IP, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mouf.net X-Virus-Scanned: clamav-milter 0.99 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 21:30:40 -0000 On 04/28/16 01:52 PM, Mark Millard wrote: > > Just FYI in case gcc49 is also of a different vintage vs. what I used: > >> # pkg info 'gcc*' >> gcc49-4.9.4.s20160406 >> gcc6-devel-6.0.1.s20160421 > > (I still have no access to the log file via the URL.) > The gcc49 is gcc49-4.9.4.s20160210, though I think the version of gcc6-devel is more relevant. Host is back up now. Steve From owner-freebsd-ppc@freebsd.org Thu Apr 28 22:58:15 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35676B1D96D for ; Thu, 28 Apr 2016 22:58:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-155.reflexion.net [208.70.211.155]) (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 DBD091AFB for ; Thu, 28 Apr 2016 22:58:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30247 invoked from network); 28 Apr 2016 22:58:39 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Apr 2016 22:58:39 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 28 Apr 2016 18:58:43 -0400 (EDT) Received: (qmail 8389 invoked from network); 28 Apr 2016 22:58:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Apr 2016 22:58:42 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 106D31C43D5; Thu, 28 Apr 2016 15:58:08 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains? From: Mark Millard In-Reply-To: <572280F5.7020202@FreeBSD.org> Date: Thu, 28 Apr 2016 15:58:12 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <92808382-E164-479D-BF9E-16B59192B7BA@dsl-only.net> References: <34C0599F-044B-46ED-AF60-0F0E98876E2F@dsl-only.net> <571C0297.3050801@FreeBSD.org> <28FDFFB4-02CC-40CB-ACAC-828BA8E71A37@dsl-only.net> <00621189-D577-4E3F-8BAB-4B315B690209@dsl-only.net> <571CC2F2.2060601@FreeBSD.org> <571D0146.5060200@FreeBSD.org> <572216FD.9030700@FreeBSD.org> <1ABC33D7-86DB-4CA7-BA48-A995AB6DEA7C@dsl-only.net> <423516E1-02AA-49DE-AE30-6DF7418C50C4@dsl-only.net> <572280F5.7020202@FreeBSD.org> To: Steve Wills X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 22:58:15 -0000 Now that I can look at your log (gcc6-devel-6.0.0.s20160320.log) we have = a WITH_LIB32=3D vs. WITHOUT_LIB32=3D difference (potential differences = was one of the reasons I early on included my src.conf content such = such): In your gcc6-devel-6.0.0.s20160320.log .libs/close.o without -m32 (so 64 = bit) built fine but with -m32 did not. Would disabling lib32 support for powerpc64 be better than the = completely-BROKEN classification? Background notes for why I omit lib32 support: My buildworld's and builds of gcc*'s do not include lib32 because, while = a devel/powerpc64-gcc (xtoolchain) based buildworld for WITH_LIB32=3D = produces a lib32, the lib32 context does not work when used. This is due = to crtbeginS code problems related to R30 use (bad address in R30 = dereferenced). (Native builds and cross builds from amd64 both produce = the bad code.) I have not figured out why the crtbeginS code produced by = devel\powerpc64-gcc is as it is --or how to control that code to be what = FreeBSD needs for lib32 use. Until I figure that out I normally use WITHOUT_LIB32=3D in my src.conf = and I always build powerpc64 lang/gcc*'s without lib32 support. Your lib32 context seems to have trouble finding = declarations/definitions from headers, such as for strdup and free. = Quoting the .libs/close.o related error messages for when -m32 is = involved: > ../../.././../gcc-6-20160320/libgfortran/io/close.c: In function = 'st_close': > ../../.././../gcc-6-20160320/libgfortran/io/close.c:75:11: error: = implicit declaration of function 'strdup' = [-Werror=3Dimplicit-function-declaration] > path =3D strdup (u->filename); > ^~~~~~ > ../../.././../gcc-6-20160320/libgfortran/io/close.c:75:11: warning: = incompatible implicit declaration of built-in function 'strdup' > ../../.././../gcc-6-20160320/libgfortran/io/close.c:85:15: warning: = incompatible implicit declaration of built-in function 'strdup' > path =3D strdup (u->filename); > ^~~~~~ > ../../.././../gcc-6-20160320/libgfortran/io/close.c:96:4: error: = implicit declaration of function 'free' = [-Werror=3Dimplicit-function-declaration] > free (path); > ^~~~ > ../../.././../gcc-6-20160320/libgfortran/io/close.c:96:4: warning: = incompatible implicit declaration of built-in function 'free' > ../../.././../gcc-6-20160320/libgfortran/io/close.c:96:4: note: = include '' or provide a declaration of 'free' > cc1: some warnings being treated as errors =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-28, at 2:30 PM, Steve Wills wrote: On 04/28/16 01:52 PM, Mark Millard wrote: >=20 > Just FYI in case gcc49 is also of a different vintage vs. what I used: >=20 >> # pkg info 'gcc*' >> gcc49-4.9.4.s20160406 >> gcc6-devel-6.0.1.s20160421 >=20 > (I still have no access to the log file via the URL.) >=20 The gcc49 is gcc49-4.9.4.s20160210, though I think the version of gcc6-devel is more relevant. Host is back up now. Steve