From owner-freebsd-current@freebsd.org Sun Apr 3 07:02:30 2016 Return-Path: Delivered-To: freebsd-current@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 0AF8CB005FB for ; Sun, 3 Apr 2016 07:02:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 BF37E12F6 for ; Sun, 3 Apr 2016 07:02:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18283 invoked from network); 3 Apr 2016 07:02:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 3 Apr 2016 07:02:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Sun, 03 Apr 2016 03:02:13 -0400 (EDT) Received: (qmail 23008 invoked from network); 3 Apr 2016 07:02:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 3 Apr 2016 07:02:13 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network 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 29735B1E001; Sat, 2 Apr 2016 23:06:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: Date: Sat, 2 Apr 2016 23:06:48 -0700 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <53DAD70E-8DE4-4DBA-BF88-AD7F51B0B816@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> <5334F356-982F-40CA-9009-41B59AAC8665@dsl-only.net> To: Warner Losh , Bryan Drewery X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 07:02:30 -0000 On 2016-Apr-2, at 3:59 PM, Mark Millard wrote: > [My testing for the likes of the below does not yet extend outside = powerpc64 contexts.] >=20 > For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc = use with, say, gcc49 materials as the so-called "host" compiler tools I = have not yet found a way around using the workaround: >=20 >> # ls -l /usr/lib/libstdc++.* >> lrwxr-xr-x 1 root wheel 17 Feb 23 00:09 /usr/lib/libstdc++.a -> = /usr/lib/libc++.a >> lrwxr-xr-x 1 root wheel 18 Feb 23 00:09 /usr/lib/libstdc++.so -> = /usr/lib/libc++.so >=20 >=20 >=20 > But I appear to now have a src.conf (or a family of them) that avoids = needing workarounds in /usr/local/include and /usr/local/lib for = filename conflicts. This is based on CC/CXX ("HOST") and XCC/XCXX = ("CROSS") in src.conf being the likes of: >=20 > "HOST" (CC/CXX): >> 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 >=20 > and. . . >=20 > "CROSS" (XCC/XCXX): >> TO_TYPE=3Dpowerpc64 >> TOOLS_TO_TYPE=3D${TO_TYPE} >> . . . >> VERSION_CONTEXT=3D11.0 >> . . . >> = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c >> = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ >=20 > In other words: CROSS use is already handled for /usr/local/. . . just = given the compiler paths but some special src.conf adjustments beyond = compiler paths were needed for HOST. >=20 > So far it appears that gcc49 materials can be used in "CROSS" and/or = powerpc64-gcc materials can be used in "HOST" via just appropriate = compiler-path editing. (I have jumped to testing -r297514 but am still = doing various build tests. So this aspect is subject to updates.) It = appears to be possible to use just one compiler/tool family --but in the = 2 different ways-- instead of using a mix of 2 compiler/tool families. >=20 > Historically I've not gotten gcc variants to make a working lib32 for = powerpc64 and I've yet to retest this: So no claims about the lib32 = status are implied here. (The problem was code in crtbeginS that = arbitrarily used R30 in a way that the context was not set up for and so = crtbeginS code was dereferencing arbitrary addresses.) I probably knew this someplace in the back of my head but gcc49 does not = handle -fformat-extensions (quoting the script log): > --- accf_data.o --- > env /usr/local/bin/gcc49 -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerp > c64/usr/src/tmp -B/usr/local/powerpc64-portbld-freebsd11.0/bin/ -O2 = -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc = -DHAVE_KERNEL_OPTION_HEADERS -include = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG/op= t_global.h -I. -I/usr/src/sys -fno-common -g -mlongcall = -fno-omit-frame-pointer = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG = -MD -MF.depend.accf_data.o -MTaccf_data.o -mno-altivec -ffreestanding = -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls = -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes = -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign = -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option = -Wno-unknown-pragmas -Wno-error=3Dinline -Wno-error=3Denum-compare = -Wno-error=3Dunused-but-set-variable = -Wno-error=3Daggressive-loop-optimizations = -Wno-error=3Dmaybe-uninitialized -Wno-error=3Darray-bounds = -Wno-error=3Daddress -Wno-error=3Dcast-qual -Wno-error=3Dsequence-point = -Wno-error=3Dattributes -Wno-error=3Dstrict-overflow = -Wno-error=3Doverflow -v -finline-limit=3D15000 -fms-extensions --param = inline-unit-growth=3D100 --param large-function-growth=3D1000 = -msoft-float -mcall-aixdesc -std=3Diso9899:1999 -c = /usr/src/sys/modules/accf_data/../../netinet/accf_data.c -o accf_data.o > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/gcc49 > gcc49: error: unrecognized command line option '-fformat-extensions' > Target: powerpc64-portbld-freebsd11.0 > Configured with: ./../gcc-4.9-20160210/configure --disable-multilib = --disable-bootstrap --disable-nls --enable-gnu-indirect-function = --libdir=3D/usr/local/lib/gcc49 --libexecdir=3D/usr/local/libexec/gcc49 = --program-suffix=3D49 --with-as=3D/usr/local/bin/as = --with-gmp=3D/usr/local = --with-gxx-include-dir=3D/usr/local/lib/gcc49/include/c++/ = --with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports = Collection' --with-system-zlib --disable-libgcj = --enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc49 --build=3Dpowerpc64-portbld-freebsd11.0 > Thread model: posix > gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)=20 > *** [accf_data.o] Error code 1 So my > it appears that gcc49 materials can be used in "CROSS" is just false for gcc49, gcc5, and the like. I had hoped such would work with TARGET_ARCH=3Dpowerpc because there is = no powerpc-gcc port predefined and clang 3.8.0 is still insufficient for = this context. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-1, at 4:35 PM, Mark Millard wrote: >=20 > [Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc = has for the default include search places:] >=20 > powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in = /usr/local/include before /usr/include : see below. >=20 >> # portmaster --list-origins >> . . . >> devel/powerpc64-xtoolchain-gcc >> . . . >>=20 >> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version >> powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for = powerpc64) 5.3.0 >> Copyright (C) 2015 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There = is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR = PURPOSE. >>=20 >> # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ = - -o /dev/null >> . . . >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/powerpc64-portbld-freebsd11.0" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ= e/c++/5.3.0/backward" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> /usr/include >> End of search list. >> . . . >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > On 2016-Apr-1, at 7:25 AM, Warner Losh wrote: >=20 >=20 >=20 > On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric = wrote: > On 01 Apr 2016, at 00:44, Warner Losh wrote: >>=20 >>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery = wrote: >>> I didn't realize the ports compiler was defaulting = /usr/local/include >>> into the search path now. It does not have /usr/local/lib in the >>> default library path as far as I can tell. It's also broken for its >>> -rpath (noted in its pkg-message). So having a default >>> /usr/local/include path seems odd. >>=20 >> It has for a while now. It=E2=80=99s one of the maddening = inconsistencies that abound in this >> area. I took a poll a while ago and there seemed to be widespread = support for adding >> it to the base compiler. >=20 > This was the main reason /usr/local/include was *not* included in the > base compiler, otherwise it would unpredictably pick up headers in > /usr/local/include during builds. You can never know which = conflicting > headers a certain user has installed in /usr/local/include... :) >=20 > That's why it shouldn't be *FIRST*, not why it shouldn't be there > at all. >=20 >>> Adding -isystem /usr/include to fix this is probably possible but >>> there's a risk someone will remove it as redundant. In this case I = wish >>> /usr/include was first but I'm not sure what impact that would have = on >>> consumers expecting /usr/local/include (and /usr/local/lib) = overrides to >>> work, though they would need to pass a -L /usr/local/lib anyhow and >>> would likely be passing -I /usr/local/lib too. >>=20 >> /usr/include should be first. But it isn=E2=80=99t. That=E2=80=99s = another inconsistency that was found >> when we looked at /usr/local stuff. Someone recently added = /usr/local/bin to the path, >> if I recall correctly. >=20 > Isn't that a bit of a bikeshed? I guess some people would just as = well > prefer /usr/local/include to be first, just like some people prefer > /usr/local/bin before /usr/bin in their PATH. >=20 > Sigh. No. /usr/local is moving into many different things in the base = and ports. We should > do it in a consistent way. What we have now is not consistent and = somewhat brittle. >=20 > In any case, if such paths are added to external compilers, we better > make sure almost everything in buildworld uses -nostdinc, and = specifying > exactly the include directories we need, and no others. Cumbersome, = but > maybe for a good cause. >=20 > That's the non-brittle solution here. An over-reliance on defaults = makes it > difficult to ensure other compilers will work, especially ones we = don't > tightly control the defaults for. >=20 > Warner