From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 29 08:22:42 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A5EA48F for ; Sun, 29 Mar 2015 08:22:42 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 569E89A for ; Sun, 29 Mar 2015 08:22:41 +0000 (UTC) Received: (qmail 26049 invoked from network); 29 Mar 2015 08:22:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Mar 2015 08:22:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sun, 29 Mar 2015 04:22:40 -0400 (EDT) Received: (qmail 6622 invoked from network); 29 Mar 2015 08:22:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Mar 2015 08:22:39 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 37388B1E008; Sun, 29 Mar 2015 01:13:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: FYI: Things that I've noticed for powerpc64-xtoolchain-gcc... Date: Sun, 29 Mar 2015 01:13:05 -0700 Message-Id: <056FF51B-CB8A-42E9-A7BA-B0A022F2640C@dsl-only.net> To: rodrigc@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 08:22:42 -0000 You [Craig Rodrigues] seem to be checking some ??-xtoolchain-gcc things = officially. I've some user-experience notes from happening to use = powerpc64-xtoolchain-gcc in my exploration of FreeBSD. Hopefully some of = it might be of interest. It groups together information from various = notices as I was doing the explorations. I've been exploring FreeBSD, in part using powerpc64-xtoolchain-gcc = --but on a powerpc64 11.0-CURRENT environment for the points at hand: A = form of self-hosting xtoolchain use. As stands I'm limited to powerpc64 = and powerpc contexts for FreeBSD, PowerMacs specifically. So I might = over infer general ??-xtoolchain-gcc properties. My use is not generally of the grab-source and buildworld/buildkernel = from scratch kind of context. The closest I came to that was rebuilding = a gcc 4.2.1 built powerpc64 11.0-CURRENT to be a powerpc64-gcc based = 11.0-current that had libc++ in use. After that I've updated (svnlite update -r??????) and rebuilt a newer = 11.0-CURRENT. I'm not sure if the continuous integration or other ??-xtoolchain-gcc = testing checks on rebuild-for-update kind of context or not. One of the = things of note for me is specific to that kind of context where headers = and libraries temporarily have both old and new vintages around and the = right ones need to be used in specific stages. Other aspects of my use = might also go outside the range of your activity as well. The primary things that I've run into include: A) Rebuilds from updated sources were picking up old headers (from, for = example, /usr/include) and old libraries, not just for legacy/ where = such makes sense. B) I had a specific problem originally with atf-c++ finding the C++ = standard library headers. I added a specific -I for what was = ${WORLDTMP}/usr/include/c++/v1 in order for it to find the files. I also = put in a matching -L for /usr/obj/usr/src/lib/libc++ . C) powerpc64-gcc automatically looks in /usr/local/include for header = files (like most such ports) and this can pick up the wrong file(s). I = ended up using the manual policy of renaming /usr/local/include/iconv.h = during buildworld/buildkernel so that it would not be found and used = where the build should have found a file with different content from my = /usr/src/... area (or its WORLDTMP copy). D) I've been limited to WITHOUT_BOOT=3D WITHOUT_LIB32=3D by being unable = to get the 32-bit environment activity to work: = CROSS_TOOLCHAIN=3Dpowerpc64-gcc use did not allow the -melf32ppc_fbsd . = Does targeting i386 for BOOT and LIB32 from amd64 have a similar problem = with -melf_i386_fbsd ? E) I've been limited to WITHOUT_GCC_BOOTSTRAP=3D by XCC being a full = path making the build environment ignore WITH_GCC_BOOTSTRAP=3D . = Similarly WITH_GCC=3D does not actually cause gcc 4.2.1 to be built. (I = wanted WITHOUT_GNUCXX=3D in order to try libc++ only. So I've not tried = WITH_GNUCXX=3D .) F) I've been limited to WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D = WITHOUT_LLDB=3D by various issues when clang related builds are = involved. I'll not go into details. G) Last I tried it powerpc64-xtoolchain-gcc does not correctly install = itself automatically when one attempts to install it in a powerpc64-host = context. (It installs fine on a powerpc (non-64) host context.) This may = be associated with the same points that make the distinction between = /usr/obj/powerpc.powerpc64/usr/src/ (on/in powerpc (non-64)) and = /usr/obj/usr/src/ (on/in powerpc64) as a default path: in part the = errors were empty file name prefixes vs. filled-in prefixes. H) After the gcc 4.2.1 -> 4.9.1 bootstrap I had to rebuild powerpc64-gcc = in order to get the -pg compiles to always work: without that at least = one required example of such a compile crashed the compiler every time = it was tried. All -pg compiles worked fine after the rebuild. (I used = gcc5 to rebuild 4.9.1 because of (G) ending up involved otherwise.) = Before, when still booted from the gcc-4.2.1-based world, the original = gcc 4.9.1 compiler did not crash for -pg compiles. I) Trying to use powerpc64-xtoolchain-gcc from a powerpc (non-64) host = does not work. One aspect is tool chain related: C/C++/assembler usage = need to be told to be 64-bit such that, for example, __powerpc64__ ends = up defined for pre-processor use. That is not happening and incorrect = processor generated files result. For example the assembler reports = syntax errors from lack of definitions related to TOC use for powerpc64. There are some work arounds involved for things very powerpc64/powerpc = context specific, such as some Makefile*'s forcing use of CC:=3Dgcc . = I've not noted such things above: The above targets what I'd guess might = be more general issues. I've also not noted when 11.0-CURRENT has = required a few files to have specific versions picked out that did not = match the snapshot I was generally using at the time. My current context for this is: > # freebsd-version -ku; uname -apKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r280598M: Fri = Mar 27 18:26:08 PDT 2015 = root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc = powerpc64 1100066 1100066 > # dmesg | head > ... > FreeBSD 11.0-CURRENT #0 r280598M: Fri Mar 27 18:26:08 PDT 2015 > root@FBSDG5C0:/usr/obj/usr/src/sys/GENERIC64vtsc-NODEBUG powerpc > gcc version 4.9.1 (FreeBSD Ports Collection for powerpc64)=20 > ... I originally bootstrapped using -r279514. After that I attempted = rebuilding 279514 various times exploring what I could enable = successfully vs. what I could not. -r280598 was my first attempt to = svnlite upgrade then rebuild. The 4.2.1 gcc is not present. Nor has clang been built: 3.4.1 was = removed by make delete-old after the initial bootstrap. I'm using = powerpc64-gcc as the only system compiler after the bootstrap. (This = fits with (E) above.) > make -j 8 CROSS_TOOLCHAIN=3Dpowerpc64-gcc \ > WITHOUT_CLANG_BOOTSTRAP=3D WITHOUT_CLANG=3D WITHOUT_CLANG_IS_CC=3D \ > WITHOUT_LLDB=3D \ > WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D \ > WITHOUT_BOOT=3D WITHOUT_LIB32=3D \ > buildworld buildkernel \ > KERNCONF=3DGENERIC64vtsc-NODEBUG \ > TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 For the below: Remember, no 4.2.1 gcc and no clang. So powerpc64-gcc = also has to cover what those would normally be used for, not just the = XCC, XCXX, XCPP usage. (powerpc and powerpc64 via clang is not a = supported combination yet anyway.) > # more /etc/src.conf=20 > NO_WERROR=3D > WITH_LIBCPLUSPLUS=3D > CC=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc > CXX=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > CPP=3D/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp > CROSS_BINUTILS_PREFIX=3D/usr/local/powerpc64-freebsd/bin/ > X_COMPILER_TYPE=3Dgcc > #CFLAGS+=3D-L/usr/obj/usr/src/tmp/usr/lib/. > # The order of the two CXXFLAGS additions below is important. > CXXFLAGS+=3D-I/usr/obj/usr/src/tmp/usr/include/c++/v1/. -std=3Dgnu++11 = -L/usr/obj/usr/src/lib/libc++/. > CXXFLAGS+=3D-I/usr/include/c++/v1/. -std=3Dgnu++11 -L/usr/lib/. (I make no claim that the above is a general solution but with some care = about how to do builds it has allowed the experiments that I've done. I = sometimes have used /usr/srcC/ instead of /usr/src/ : I have two = 11.0-CURRENT source trees.) > # more /etc/make.conf=20 > WRKDIRPREFIX=3D/usr/obj/portswork > #WITH_DEBUG=3D > MALLOC_PRODUCTION=3D > # svnlite st /usr/src --no-ignore > ? /usr/src/.snap > ? /usr/src/restoresymtable > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /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/ofw/ofwcall64.S All of the above files that are relevant existed and were in use long = before I started the powerpc64-xtoolchain-gcc related explorations. = ofw_machdep.c is tied to a PowerMac-specific change for reliable = booting. The db_'s and ofwcall64.S are tied to getting information from = early-boot crashes if I get any more. The GENERIC*'s relate to that = early-information gathering and to disabling ps3 so that I can then also = have both vt and sc enabled. As this has been an exploration of the unfamiliar, I've had false = starts, backtracking, and the like. While I've learned a bunch I doubt = that I could start over and get to where I am by a step-by-step = procedure that avoided backtracking, pondering, retries, and so on. In = some respects I've been lucky that certain types of changes did not = happen between my original and upgraded vintages: things would not have = worked that did work. =3D=3D=3D Mark Millard markmi at dsl-only.net