From owner-freebsd-toolchain@freebsd.org Sat Apr 2 22:59:30 2016 Return-Path: Delivered-To: freebsd-toolchain@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 C180EB004F0 for ; Sat, 2 Apr 2016 22:59: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 824DE105D for ; Sat, 2 Apr 2016 22:59:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27365 invoked from network); 2 Apr 2016 22:59:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Apr 2016 22:59:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Sat, 02 Apr 2016 18:59:32 -0400 (EDT) Received: (qmail 1449 invoked from network); 2 Apr 2016 22:59:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 2 Apr 2016 22:59:32 -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 3D65B1C4387; Sat, 2 Apr 2016 15:59:23 -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: <5334F356-982F-40CA-9009-41B59AAC8665@dsl-only.net> Date: Sat, 2 Apr 2016 15:59:27 -0700 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: 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-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 22:59:30 -0000 [My testing for the likes of the below does not yet extend outside = powerpc64 contexts.] 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: > # 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 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: "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 and. . . "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= ++ 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. 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. 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.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Apr-1, at 4:35 PM, Mark Millard wrote: [Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc has = for the default include search places:] powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in /usr/local/include = before /usr/include : see below. > # 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. > . . . =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