From owner-freebsd-toolchain@freebsd.org Sun Mar 27 21:30:12 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 B1948ADF2A4 for ; Sun, 27 Mar 2016 21:30:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9BA501886 for ; Sun, 27 Mar 2016 21:30:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9786EADF2A2; Sun, 27 Mar 2016 21:30:12 +0000 (UTC) Delivered-To: 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 94BDBADF2A1 for ; Sun, 27 Mar 2016 21:30:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 383CB1885 for ; Sun, 27 Mar 2016 21:30:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::ad9c:32e8:3e6c:1da3] (unknown [IPv6:2001:7b8:3a7:0:ad9c:32e8:3e6c:1da3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id CCD432557F; Sun, 27 Mar 2016 23:30:07 +0200 (CEST) Subject: Re: boost/asio/ip/resolver_query_base.hpp:96:3: warning: all paths through this function will call itself Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B5C505BE-075E-4F8B-A2CB-2BB216E0265F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <56F58E3E.1090208@digiware.nl> Date: Sun, 27 Mar 2016 23:29:58 +0200 Cc: toolchain@freebsd.org Message-Id: References: <56F58E3E.1090208@digiware.nl> To: Willem Jan Withagen 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: Sun, 27 Mar 2016 21:30:12 -0000 --Apple-Mail=_B5C505BE-075E-4F8B-A2CB-2BB216E0265F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Mar 2016, at 20:15, Willem Jan Withagen wrote: > Any suggestions why I'm getting this warning/error in the ceph code: >=20 > In file included from log/Log.cc:12: > In file included from /usr/local/include/boost/asio.hpp:63: > In file included from = /usr/local/include/boost/asio/ip/basic_resolver.hpp:24: > In file included from = /usr/local/include/boost/asio/ip/basic_resolver_query.hpp:21: > /usr/local/include/boost/asio/ip/resolver_query_base.hpp:96:3: = warning: all paths through this function will call > itself [-Winfinite-recursion] >=20 > Could be a boost error, but I have not seen any upgrades to a newer = version. It's a boost bug. You can apply this trivial upstream fix: = https://github.com/boostorg/asio/commit/9e757605709cace0fc048ad284b2d6aa3a= e784ac -Dimitry --Apple-Mail=_B5C505BE-075E-4F8B-A2CB-2BB216E0265F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlb4UN8ACgkQsF6jCi4glqOkbACg44F78eSVNn84g2F38dUgPWix oGsAn2Uc+rsAlf5XAU5tYutaMnBou9rP =BGLk -----END PGP SIGNATURE----- --Apple-Mail=_B5C505BE-075E-4F8B-A2CB-2BB216E0265F-- From owner-freebsd-toolchain@freebsd.org Sun Mar 27 21:33:12 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 A18C7ADF3F3 for ; Sun, 27 Mar 2016 21:33:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABD11B16 for ; Sun, 27 Mar 2016 21:33:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8A0F6ADF3F2; Sun, 27 Mar 2016 21:33:12 +0000 (UTC) Delivered-To: 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 89B62ADF3F1 for ; Sun, 27 Mar 2016 21:33:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A83651B14; Sun, 27 Mar 2016 21:33:11 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::ad9c:32e8:3e6c:1da3] (unknown [IPv6:2001:7b8:3a7:0:ad9c:32e8:3e6c:1da3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2ADCC25589; Sun, 27 Mar 2016 23:33:03 +0200 (CEST) Subject: Re: CXXSTD=c++11 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_73059E3B-2345-46FE-86B3-1AF41FF703E7"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <56F475CB.8020107@FreeBSD.org> Date: Sun, 27 Mar 2016 23:33:02 +0200 Cc: toolchain@FreeBSD.org Message-Id: <222A6D82-ED88-4F93-869E-6615BFEE0441@FreeBSD.org> References: <56F46BE0.7080909@FreeBSD.org> <43ABA5F3-60E0-4A29-9698-B345A3DA0A8B@FreeBSD.org> <56F46E1B.4010605@FreeBSD.org> <56F46F67.2000807@FreeBSD.org> <7B77010A-B377-4B1A-835A-D48F59E5290D@FreeBSD.org> <56F475CB.8020107@FreeBSD.org> To: 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: Sun, 27 Mar 2016 21:33:12 -0000 --Apple-Mail=_73059E3B-2345-46FE-86B3-1AF41FF703E7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 25 Mar 2016, at 00:18, Bryan Drewery wrote: > > On 3/24/2016 4:16 PM, Dimitry Andric wrote: >> On 24 Mar 2016, at 23:54, Dimitry Andric wrote: >>> >>> On 24 Mar 2016, at 23:51, Bryan Drewery wrote: >> ... >>>> It fails without -std=c++11 (there's more discussion in that link and in >>>> PR 205453). >>> >>> Yeah, I also commented on PR 205453 in the past, but I still don't >>> understand where the external gcc gets its _Static_assert macro from. >>> Or whether it gets it at all. Maybe we should place a hack for this in >>> sys/cdefs.h? We shouldn't litter contrib code with #ifdef GCC_VERSION >>> blocks. >> >> Hm, hacking around in cdefs.h also doesn't really help, because gcc >> refuses to recognize either _Static_assert or static_assert when it's >> not in C++11 mode. Reading back https://reviews.freebsd.org/D1390, I >> see that I originally wanted to avoid building libcxxrt with -std=c++11. >> This was so you could even build it with gcc 4.2.1 from base. >> >> However, it really doesn't make much sense to do so, and upstream >> libcxxrt simply uses static_assert directly, and requires -std=c++11. I >> will update the libcxxrt build to do so, probably tomorrow. >> > > Sounds good. Done in r297299 [1]. I also imported libc++ r255683 [2], which should fix llvm-cov compilation with g++, in r297322 [3]. -Dimitry [1] https://svnweb.freebsd.org/changeset/base/297299 [2] http://reviews.llvm.org/rL255683 [3] https://svnweb.freebsd.org/changeset/base/297322 --Apple-Mail=_73059E3B-2345-46FE-86B3-1AF41FF703E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlb4UY4ACgkQsF6jCi4glqOT8wCfRanHMTeKfjRRO/KxIhYIJ+Ij n/4AoIv7xInkqgdqdz+FMaOwgOqTz6zt =72Cv -----END PGP SIGNATURE----- --Apple-Mail=_73059E3B-2345-46FE-86B3-1AF41FF703E7-- From owner-freebsd-toolchain@freebsd.org Sun Mar 27 21:59:47 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 1428DADF937 for ; Sun, 27 Mar 2016 21:59:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id F38AD1208 for ; Sun, 27 Mar 2016 21:59:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: by mailman.ysv.freebsd.org (Postfix) id F2D8AADF936; Sun, 27 Mar 2016 21:59:46 +0000 (UTC) Delivered-To: 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 F27ACADF935 for ; Sun, 27 Mar 2016 21:59:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (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 BBD231207; Sun, 27 Mar 2016 21:59:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 418E11534CA; Sun, 27 Mar 2016 23:59:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLEFCUnwoBjq; Sun, 27 Mar 2016 23:59:34 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:793e:bab9:1cc9:7a02] (unknown [IPv6:2001:4cb8:3:1:793e:bab9:1cc9:7a02]) by smtp.digiware.nl (Postfix) with ESMTP id 52289153401; Sun, 27 Mar 2016 23:46:29 +0200 (CEST) Subject: Re: boost/asio/ip/resolver_query_base.hpp:96:3: warning: all paths through this function will call itself To: Dimitry Andric References: <56F58E3E.1090208@digiware.nl> Cc: toolchain@freebsd.org From: Willem Jan Withagen Organization: Digiware Management b.v. Message-ID: <56F854B3.30001@digiware.nl> Date: Sun, 27 Mar 2016 23:46:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Sun, 27 Mar 2016 21:59:47 -0000 On 27-3-2016 23:29, Dimitry Andric wrote: > On 25 Mar 2016, at 20:15, Willem Jan Withagen wrote: >> Any suggestions why I'm getting this warning/error in the ceph code: >> >> In file included from log/Log.cc:12: >> In file included from /usr/local/include/boost/asio.hpp:63: >> In file included from /usr/local/include/boost/asio/ip/basic_resolver.hpp:24: >> In file included from /usr/local/include/boost/asio/ip/basic_resolver_query.hpp:21: >> /usr/local/include/boost/asio/ip/resolver_query_base.hpp:96:3: warning: all paths through this function will call >> itself [-Winfinite-recursion] >> >> Could be a boost error, but I have not seen any upgrades to a newer version. > > It's a boost bug. You can apply this trivial upstream fix: > > https://github.com/boostorg/asio/commit/9e757605709cace0fc048ad284b2d6aa3ae784ac Perhaps trivial, but also subtle Thanx, --WjW From owner-freebsd-toolchain@freebsd.org Sun Mar 27 22:32:50 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 D7005ADF0DE for ; Sun, 27 Mar 2016 22:32:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 C66571580 for ; Sun, 27 Mar 2016 22:32:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2RMWoPE091083 for ; Sun, 27 Mar 2016 22:32:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 205453] 11.0-CURRENT libcxxrt/guard.cc uses C11's _Static_assert in conditionally-compiled C++ code and when it is used buildworld fails for syntax errors in g++ compilers Date: Sun, 27 Mar 2016 22:32:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Sun, 27 Mar 2016 22:32:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205453 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --- Comment #5 from Dimitry Andric --- Fixed in r297299. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Mar 29 14:46:09 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 9A7CEAE109A for ; Tue, 29 Mar 2016 14:46:09 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D5D3E19A3 for ; Tue, 29 Mar 2016 14:46:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA14419 for ; Tue, 29 Mar 2016 17:45:58 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1akuu6-0004wG-AM for freebsd-toolchain@FreeBSD.org; Tue, 29 Mar 2016 17:45:58 +0300 To: freebsd-toolchain@FreeBSD.org From: Andriy Gapon Subject: warning: DWARF2 only supports one section per compilation unit Message-ID: <56FA94ED.1060402@FreeBSD.org> Date: Tue, 29 Mar 2016 17:45:01 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: Tue, 29 Mar 2016 14:46:09 -0000 I've noticed many messages like the following during amd64 buildworld with very recent head: > warning: DWARF2 only supports one section per compilation unit > .section .note.GNU-stack,"",%progbits Reported sections varied (e.g. there was .rodata). The messages seem to be related to .s files. I hope that those are harmless? -- Andriy Gapon From owner-freebsd-toolchain@freebsd.org Tue Mar 29 17:49: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 ECE3EAE2314 for ; Tue, 29 Mar 2016 17:49:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADB23180E; Tue, 29 Mar 2016 17:49:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::4513:c3a7:b0b8:ff47] (unknown [IPv6:2001:7b8:3a7:0:4513:c3a7:b0b8:ff47]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2AA1F696F; Tue, 29 Mar 2016 19:49:27 +0200 (CEST) Subject: Re: warning: DWARF2 only supports one section per compilation unit Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_53FCA829-50F9-4853-8073-0BC39C5651F6"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <56FA94ED.1060402@FreeBSD.org> Date: Tue, 29 Mar 2016 19:49:14 +0200 Cc: freebsd-toolchain@FreeBSD.org Message-Id: References: <56FA94ED.1060402@FreeBSD.org> To: Andriy Gapon 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: Tue, 29 Mar 2016 17:49:31 -0000 --Apple-Mail=_53FCA829-50F9-4853-8073-0BC39C5651F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Mar 2016, at 16:45, Andriy Gapon wrote: >=20 > I've noticed many messages like the following during amd64 buildworld = with very > recent head: >=20 >> warning: DWARF2 only supports one section per compilation unit >> .section .note.GNU-stack,"",%progbits >=20 > Reported sections varied (e.g. there was .rodata). > The messages seem to be related to .s files. > I hope that those are harmless? These are harmless, and have been showing up for at least a year now. Clang is just notifying you that due to DWARF2 limitations, it will not emit debug info for more than one code section. All such warnings in our tree are about artificially added sections, such as .note.GNU-stack, .reloc and __xen_guest, and it is not likely that anybody cares that those sections will not have debug info. Lastly, I never found an option to shut up the warnings. Well, apart from using -gdwarf-4. :-) -Dimitry --Apple-Mail=_53FCA829-50F9-4853-8073-0BC39C5651F6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlb6wCYACgkQsF6jCi4glqNxYwCeNT0niNmQcjk5RvIjZbjj//RA SzgAoPoVScz97R0dC1ZxQkeji/aqkf7y =LzL7 -----END PGP SIGNATURE----- --Apple-Mail=_53FCA829-50F9-4853-8073-0BC39C5651F6-- From owner-freebsd-toolchain@freebsd.org Tue Mar 29 17:58:43 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 4842BAE25A1 for ; Tue, 29 Mar 2016 17:58:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CF57A1CA1; Tue, 29 Mar 2016 17:58:42 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u2THwcqM026933 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 29 Mar 2016 20:58:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u2THwcqM026933 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u2THwc8n026932; Tue, 29 Mar 2016 20:58:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Mar 2016 20:58:38 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Andriy Gapon , freebsd-toolchain@FreeBSD.org Subject: Re: warning: DWARF2 only supports one section per compilation unit Message-ID: <20160329175838.GP1741@kib.kiev.ua> References: <56FA94ED.1060402@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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: Tue, 29 Mar 2016 17:58:43 -0000 On Tue, Mar 29, 2016 at 07:49:14PM +0200, Dimitry Andric wrote: > These are harmless, and have been showing up for at least a year now. > Clang is just notifying you that due to DWARF2 limitations, it will not > emit debug info for more than one code section. > > All such warnings in our tree are about artificially added sections, > such as .note.GNU-stack, .reloc and __xen_guest, and it is not likely > that anybody cares that those sections will not have debug info. > > Lastly, I never found an option to shut up the warnings. Well, apart > from using -gdwarf-4. :-) .note.GNU-stack should not have any content at all. Issuing the warning for empty section is pointless, and it would hide in the noise a real bug if anything migrates under the section. From owner-freebsd-toolchain@freebsd.org Wed Mar 30 01:35:36 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 451EDAE2FCE for ; Wed, 30 Mar 2016 01:35:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 0A7031CB2 for ; Wed, 30 Mar 2016 01:35:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30277 invoked from network); 30 Mar 2016 01:35:26 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 30 Mar 2016 01:35:26 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Tue, 29 Mar 2016 21:35:19 -0400 (EDT) Received: (qmail 21452 invoked from network); 30 Mar 2016 01:35:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 Mar 2016 01:35:18 -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 4CE221C4075; Tue, 29 Mar 2016 18:35:22 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0 -r297369: _el_fn_sh_complete missing in buildworld; /usr/obj/. . ./lib/libedit/ has no filecomplete.* Message-Id: <97E93CA6-3F0A-47C8-BAE6-1B6866EED3CB@dsl-only.net> Date: Tue, 29 Mar 2016 18:35:27 -0700 To: FreeBSD PowerPC ML , FreeBSD Current , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Wed, 30 Mar 2016 01:35:36 -0000 Going from 11.0-CURRENT -r297048 to -r297369: buildworld after svnlite = update: /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/. . . ends up with no = filecomplete.* but the build tries to use what would be some of its contents = (_el_fn_sh_complete) The details. . . > --- all_subdir_bin --- > --- sh.full --- > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc > 64-freebsd/bin/ -O2 -pipe -DSHELL -I. -I/usr/src/bin/sh -g -std=3Dgnu99 = -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k = -Wno-uninitialized -Wno-pointer-sign -Wno-error=3Dunused-function -W > no-error=3Denum-compare -Wno-error=3Dlogical-not-parentheses = -Wno-error=3Dbool-compare -Wno-error=3Duninitialized = -Wno-error=3Darray-bounds -Wno-error=3Dclobbered -Wno-error=3Dcast-align = -Wno-error=3Dextra -Wno-error > =3Dattributes -Wno-error=3Dinline -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-value -Wno-error=3Dstrict-aliasing = -Wno-error=3Daddress -o sh.full alias.o arith_yacc.o arith_yylex.o cd.o = echo.o error. > o eval.o exec.o expand.o histedit.o input.o jobs.o kill.o mail.o = main.o memalloc.o miscbltin.o mystring.o options.o output.o parser.o = printf.o redir.o show.o test.o trap.o var.o builtins.o nodes.o syn > tax.o -ledit > . . . > --- all_subdir_bin --- > histedit.o:(.toc+0x10): undefined reference to `_el_fn_sh_complete' > collect2: error: ld returned 1 exit status > *** [sh.full] Error code 1 >=20 > bmake[4]: stopped in /usr/src/bin/sh > 1 error >=20 > bmake[4]: stopped in /usr/src/bin/sh > # find /usr/src -name .svn -prune -o -exec grep el_fn_sh_complete {} ; = -print | more > unsigned char _el_fn_sh_complete(EditLine *, int); > /usr/src/lib/libedit/histedit.h > _el_fn_sh_complete(EditLine *el, int ch __attribute__((__unused__))) > /usr/src/lib/libedit/filecomplete.c > _el_fn_sh_complete); > /usr/src/bin/sh/histedit.c > # find /usr/src -name .svn -prune -o -exec grep filecomplete {} \; = -print | more > Binary file /usr/src/lib/libedit matches > /usr/src/lib/libedit > #include "filecomplete.h" > /usr/src/lib/libedit/readline.c > /* $NetBSD: filecomplete.h,v 1.9 2009/12/30 22:37:40 christos Exp = $ */ > * $FreeBSD: head/lib/libedit/filecomplete.h 276881 2015-01-09 = 07:40:56Z bapt $ > /usr/src/lib/libedit/filecomplete.h > OSRCS=3D chared.c common.c el.c emacs.c fcns.c filecomplete.c help.c = \ > /usr/src/lib/libedit/Makefile > /* $NetBSD: filecomplete.c,v 1.34 2014/10/18 15:07:02 riz Exp $ = */ > __RCSID("$NetBSD: filecomplete.c,v 1.34 2014/10/18 15:07:02 riz Exp = $"); > __FBSDID("$FreeBSD: head/lib/libedit/filecomplete.c 296435 2016-03-06 = 21:32:54Z pfg $"); > #include "filecomplete.h" > /usr/src/lib/libedit/filecomplete.c > # find /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/ -name .svn = -prune -o -name "filecomplete*" -print | more > #=20 Supporting details. . . build command (self hosted on a powerpc64 PowerMac): > env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-h= ost MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain/powerpc.powerpc64 make -j 5 = buildworld buildkernel make.conf is empty. src.conf: > TO_TYPE=3Dpowerpc64 > TOOLS_TO_TYPE=3D${TO_TYPE} > FROM_TYPE=3Dpowerpc64 > TOOLS_FROM_TYPE=3D${FROM_TYPE} > VERSION_CONTEXT=3D11.0 > # > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BOOT=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > # > # LIB32 builds but does not work via gcc variants > WITHOUT_LIB32=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > WITH_DEBUG_FILES=3D > # > # > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils... > # > CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dgcc > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 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= ++ > = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > 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 > # > # > # =46rom gcc49 > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/local/bin/gcc49 > CXX=3D/usr/local/bin/g++49 > CPP=3D/usr/local/bin/cpp49 > .export CC > .export CXX > .export CPP > .endif > # > # > # TOOLS_FROM_TYPE's appropriate binutils... > # > .if ${.MAKE.LEVEL} =3D=3D 0 > = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s > = 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 > = 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 > = 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 > = 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 > 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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Mar 31 21:26:20 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 EF323AE3A51; Thu, 31 Mar 2016 21:26:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DD3F21BA3; Thu, 31 Mar 2016 21:26:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id D6916187B; Thu, 31 Mar 2016 21:26:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7FBB11FC10; Thu, 31 Mar 2016 21:26:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id kQumUtaOEmqp; Thu, 31 Mar 2016 21:26:18 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 2EB741FC08 To: Mark Millard , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <56FD95F8.3020502@FreeBSD.org> Date: Thu, 31 Mar 2016 14:26:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Thu, 31 Mar 2016 21:26:21 -0000 On 3/31/16 2:23 PM, Mark Millard wrote: > Should there be xtoolchain usage notes about avoiding /usr/local/include name conflicts and/or about how to assign CC/CXX/XCC/XCXX? > > As long as I use gcc49 tools for CC and CXX I still must do things like renaming files in /usr/local/include to avoid them interfering with system headers: Try setting X_COMPILER_TYPE=gcc as well. -- Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Thu Mar 31 21:29:49 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 8D606AE3C74 for ; Thu, 31 Mar 2016 21:29:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 BA2591D53 for ; Thu, 31 Mar 2016 21:29:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24549 invoked from network); 31 Mar 2016 21:29:44 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 21:29:44 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 17:30:09 -0400 (EDT) Received: (qmail 24404 invoked from network); 31 Mar 2016 21:30:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 21:30:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9F0261C407B; Thu, 31 Mar 2016 14:29:41 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 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: <56FD95F8.3020502@FreeBSD.org> Date: Thu, 31 Mar 2016 14:29:45 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <49DD1B97-FC9D-4CA6-B4DE-CDDAFA80920A@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD95F8.3020502@FreeBSD.org> To: 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: Thu, 31 Mar 2016 21:29:49 -0000 The src.conf that I listed in the original message included the line: > X_COMPILER_TYPE=3Dgcc So I'd already done that. Other suggestions? =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Mar-31, at 2:26 PM, Bryan Drewery wrote: On 3/31/16 2:23 PM, Mark Millard wrote: > Should there be xtoolchain usage notes about avoiding = /usr/local/include name conflicts and/or about how to assign = CC/CXX/XCC/XCXX? >=20 > As long as I use gcc49 tools for CC and CXX I still must do things = like renaming files in /usr/local/include to avoid them interfering with = system headers: Try setting X_COMPILER_TYPE=3Dgcc as well. --=20 Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Thu Mar 31 21:30:13 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 2F136AE3D2B for ; Thu, 31 Mar 2016 21:30:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 D42ED1EA9 for ; Thu, 31 Mar 2016 21:30:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2740 invoked from network); 31 Mar 2016 21:23:54 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 21:23:54 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 17:23:54 -0400 (EDT) Received: (qmail 27376 invoked from network); 31 Mar 2016 21:23:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 21:23:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0F0981C407A; Thu, 31 Mar 2016 14:23:27 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Date: Thu, 31 Mar 2016 14:23:30 -0700 Message-Id: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> Cc: Bryan Drewery To: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Thu, 31 Mar 2016 21:30:13 -0000 Recent changes have been trying to make things like = powerpc64-xtoolchain-gcc/powerpc64-gcc work better for = buildworld/buildkernel. I happen to do this on a powerpc64 context so the "cross build" is = actually self-hosted. No gcc 4.2.1 is present and clang 3.8.0 and before = have code generation problems for powerpc64 and powerpc so I avoid it = for system builds, including for stage 3. (Also, clang for powerpc64 = does not support building libstand: no soft-float support.) As of my last test (-r297465) buildworld's stage 3 failed from implicit = use of /usr/local/include materials unless I renamed various files = there. In part this is because of my using gcc49 tools for CC and for = CXX while using the powerpc64-gcc tools only for XCC and XCXX. Is there a standard or recommended way to configure things to avoid such = issues? Should powerpc64-gcc use be forced for CC and CXX as well as XCC = and XCXX? Should there be xtoolchain usage notes about avoiding /usr/local/include = name conflicts and/or about how to assign CC/CXX/XCC/XCXX? As long as I use gcc49 tools for CC and CXX I still must do things like = renaming files in /usr/local/include to avoid them interfering with = system headers: > # find /usr/local/include/ -name 'renamed*' -print > /usr/local/include/renamed_dwarf.h > /usr/local/include/atf-c/renamed_defs.h > /usr/local/include/renamed_iconv.h > /usr/local/include/renamed_libdwarf.h > /usr/local/include/renamed_histedit.h I use the likes of: > # diff -rq /usr/include /usr/local/include | grep "^Files " to find what to rename for the duration of the system builds. An example of what happens without the renames is below but I first note = the use of the name dwarf_errmsg in /usr/include vs. in = /usr/local/include (shown after the .h file rename but the build was = with the normal file name): > # find /usr/include/ -exec grep dwarf_errmsg {} \; -print > #define dwarf_errmsg(error) dwarf_errmsg_(&error) > const char *dwarf_errmsg_(Dwarf_Error *); > /usr/include/libdwarf.h > # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print > char* dwarf_errmsg(Dwarf_Error /*error*/); > /usr/local/include/renamed_libdwarf.h > # So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from = /usr/include . The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ = --and dwarf_errmsg being undefined (dwarf_errno has similar issues): > -------------------------------------------------------------- > >>> stage 3: cross tools > -------------------------------------------------------------- > . . . > --- ctfconvert.full --- > /usr/local/bin/gcc49 -O2 -pipe = -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/includ= e -I/usr/src/cddl/usr.b > in/ctfconvert/../../../cddl/contrib/opensolaris = -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris = -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head = -I/us > = r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/= common = -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools= /ctf/cvt -I/usr/src/cddl/usr.bin/ctfconvert/. > ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN = -g -std=3Dgnu99 = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include = -static -L/usr/obj/xtoolchain/powerpc.power > pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o = ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o = memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol > .o tdata.o traverse.o util.o -ldwarf -lelf -lelf -lz -lpthread = -legacy > dwarf.o: In function `die_off': > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:270: undefined reference to `dwarf_errmsg' > dwarf.o: In function `die_sibling': > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:288: undefined reference to `dwarf_errmsg' > dwarf.o: In function `die_child': > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:305: undefined reference to `dwarf_errmsg' > dwarf.o: In function `die_tag': > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:319: undefined reference to `dwarf_errmsg' > dwarf.o: In function `die_unsigned': > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:370: undefined reference to `dwarf_errmsg' > = dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris= /tools/ctf/cvt/dwarf.c:418: more undefined references to `dwarf_errmsg' = follow > dwarf.o: In function `dw_read': > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:1963: undefined reference to `dwarf_errno' > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:1971: undefined reference to `dwarf_errmsg' > = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:1977: undefined reference to `dwarf_errmsg' > collect2: error: ld returned 1 exit status > *** [ctfconvert.full] Error code 1 [Note: I have been able to remove some of my local workarounds as things = have been cleaned up recently. This area is just not one of them. = Getting powerpc64-gcc installed on a powerpc64 environment is one of = those things needing work arounds. amd64 building powerpc64-gcc has no = such issues (true cross compiler context: TARGET_ARCH=3Dpowerpc64 not = matching the host OS).] Context details: > # svnlite info /usr/src/ > Path: /usr/src > Working Copy Root Path: /usr/src > URL: https://svn0.us-west.freebsd.org/base/head > Relative URL: ^/head > Repository Root: https://svn0.us-west.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 297465 > Node Kind: directory > Schedule: normal > Last Changed Author: trasz > Last Changed Rev: 297465 > Last Changed Date: 2016-03-31 10:32:28 -0700 (Thu, 31 Mar 2016) > # freesd-version -ku; uname -aKU > su: freesd-version: not found > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #24 r297048M: Sat = Mar 19 06:12:57 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc 1100103 1100103 > Script started on Thu Mar 31 11:11:06 2016 > Command: env __MAKE_CONF=3D/root/src.configs/make.conf = SRC_ENV_CONF=3D/root/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-h= ost MAKEOBJDIRPREFIX=3D/usr/obj/xtoolchain/powerpc.powerpc64 make -j 5 = buildworld buildkernel The make.conf is empty. The src.conf is: > TO_TYPE=3Dpowerpc64 > TOOLS_TO_TYPE=3D${TO_TYPE} > FROM_TYPE=3Dpowerpc64 > TOOLS_FROM_TYPE=3D${FROM_TYPE} > VERSION_CONTEXT=3D11.0 > # > KERNCONF=3DGENERIC64vtsc-NODEBUG > TARGET=3Dpowerpc > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BOOT=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D > # > # LIB32 builds but does not work via gcc variants last I tried = (crtbeginS code problem) > WITHOUT_LIB32=3D > WITHOUT_GCC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related = bintutils... > # > CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dgcc > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > #CFLAGS+=3D-v > .if ${.MAKE.LEVEL} =3D=3D 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= ++ > = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > 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 > # > # > # =46rom gcc49 > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/local/bin/gcc49 > CXX=3D/usr/local/bin/g++49 > CPP=3D/usr/local/bin/cpp49 > .export CC > .export CXX > .export CPP > .endif > # > # > # TOOLS_FROM_TYPE's appropriate binutils... > # > .if ${.MAKE.LEVEL} =3D=3D 0 > = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s > = 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 > = 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 > = 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 > = 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 > 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 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Mar 31 21:32:13 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 0151AAE3F22; Thu, 31 Mar 2016 21:32:13 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E507C1165; Thu, 31 Mar 2016 21:32:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id D3E451B47; Thu, 31 Mar 2016 21:32:12 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 8B80F1FC87; Thu, 31 Mar 2016 21:32:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id pUSRmr_DeGA4; Thu, 31 Mar 2016 21:32:09 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com D657A1FC7E To: Mark Millard , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <56FD9757.6040709@FreeBSD.org> Date: Thu, 31 Mar 2016 14:32:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Thu, 31 Mar 2016 21:32:13 -0000 On 3/31/16 2:23 PM, Mark Millard wrote: > I use the likes of: > >> > # diff -rq /usr/include /usr/local/include | grep "^Files " > to find what to rename for the duration of the system builds. > > An example of what happens without the renames is below but I first note the use of the name dwarf_errmsg in /usr/include vs. in /usr/local/include (shown after the .h file rename but the build was with the normal file name): > Except for legacy, build-tools, bootstrap-tools, and cross-tools, none of /usr/include or /usr/local/include is supposed to be included. In those phases though it is intended that /usr/include is used. Not /usr/local/include though. What package is providing /usr/local/include/libdwarf.h? 'pkg which /usr/local/include/libdwarf.h' I ask so I can install it and recreate the issue and fix it. We likely just need to prioritize /usr/include over /usr/local/include for these phases, which gcc49 may have backwards since it has its prefix set to /usr/local from the ports build. >> > # find /usr/include/ -exec grep dwarf_errmsg {} \; -print >> > #define dwarf_errmsg(error) dwarf_errmsg_(&error) >> > const char *dwarf_errmsg_(Dwarf_Error *); >> > /usr/include/libdwarf.h >> > # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print >> > char* dwarf_errmsg(Dwarf_Error /*error*/); >> > /usr/local/include/renamed_libdwarf.h >> > # > So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from /usr/include . > > The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ --and dwarf_errmsg being undefined (dwarf_errno has similar issues): > >> > -------------------------------------------------------------- >>>>> > >>> stage 3: cross tools >> > -------------------------------------------------------------- >> > . . . >> > --- ctfconvert.full --- >> > /usr/local/bin/gcc49 -O2 -pipe -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/usr.b >> > in/ctfconvert/../../../cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/us >> > r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common >> -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt >> -I/usr/src/cddl/usr.bin/ctfconvert/. >> > ./../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu99 -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include -static -L/usr/obj/xtoolchain/powerpc.power >> > pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol >> > .o tdata.o traverse.o util.o -ldwarf -lelf -lelf -lz -lpthread -legacy >> > dwarf.o: In function `die_off': >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:270: undefined reference to `dwarf_errmsg' >> > dwarf.o: In function `die_sibling': >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:288: undefined reference to `dwarf_errmsg' >> > dwarf.o: In function `die_child': >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:305: undefined reference to `dwarf_errmsg' >> > dwarf.o: In function `die_tag': >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:319: undefined reference to `dwarf_errmsg' >> > dwarf.o: In function `die_unsigned': >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:370: undefined reference to `dwarf_errmsg' >> > dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418: more undefined references to `dwarf_errmsg' follow >> > dwarf.o: In function `dw_read': >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1963: undefined reference to `dwarf_errno' >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1971: undefined reference to `dwarf_errmsg' >> > /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1977: undefined reference to `dwarf_errmsg' >> > collect2: error: ld returned 1 exit status >> > *** [ctfconvert.full] Error code 1 > -- Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Thu Mar 31 22:02:33 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 0B9F7AE4AD1 for ; Thu, 31 Mar 2016 22:02:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 BBB901208 for ; Thu, 31 Mar 2016 22:02:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17459 invoked from network); 31 Mar 2016 22:02:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 22:02:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 18:02:35 -0400 (EDT) Received: (qmail 23771 invoked from network); 31 Mar 2016 22:02:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 22:02:34 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EAFED1C4061; Thu, 31 Mar 2016 15:02:25 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 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: <56FD9757.6040709@FreeBSD.org> Date: Thu, 31 Mar 2016 15:02:29 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> To: 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: Thu, 31 Mar 2016 22:02:33 -0000 > On 2016-Mar-31, at 2:32 PM, Bryan Drewery = wrote: >=20 > On 3/31/16 2:23 PM, Mark Millard wrote: >> I use the likes of: >>=20 >>>> # diff -rq /usr/include /usr/local/include | grep "^Files " >> to find what to rename for the duration of the system builds. >>=20 >> An example of what happens without the renames is below but I first = note the use of the name dwarf_errmsg in /usr/include vs. in = /usr/local/include (shown after the .h file rename but the build was = with the normal file name): >>=20 >=20 > Except for legacy, build-tools, bootstrap-tools, and cross-tools, none > of /usr/include or /usr/local/include is supposed to be included. In > those phases though it is intended that /usr/include is used. Not > /usr/local/include though. >=20 > What package is providing /usr/local/include/libdwarf.h? 'pkg which > /usr/local/include/libdwarf.h' I ask so I can install it and recreate > the issue and fix it. Here is the list for the things I renamed, including for dwarf.h : > # pkg which /usr/local/include/dwarf.h /usr/local/include/libdwarf.h = /usr/local/include/atf-c/defs.h /usr/local/include/iconv.h = /usr/local/include/histedit.h > /usr/local/include/dwarf.h was installed by package libdwarf-20130207 > /usr/local/include/libdwarf.h was installed by package = libdwarf-20130207 > /usr/local/include/atf-c/defs.h was installed by package atf-0.21 > /usr/local/include/iconv.h was not found in the database > /usr/local/include/histedit.h was installed by package = libedit-3.1.20150325_1 It looks like iconv.h is from something later removed but was not = cleaned out at the time. I have /usr/local/include/readline/ material = from the same time frame: > # ls -lt /usr/local/include/ > .. . . > -rw-r--r-- 1 root wheel 12733 Apr 22 2015 mpc.h > -rw-r--r-- 1 root wheel 9348 Mar 12 2015 renamed_iconv.h > drwxr-xr-x 2 root wheel 512 Mar 12 2015 readline > # ls -lt /usr/local/include/readline > total 80 > -rw-r--r-- 1 root wheel 3193 Mar 12 2015 rltypedefs.h > -rw-r--r-- 1 root wheel 2438 Mar 12 2015 rlconf.h > -rw-r--r-- 1 root wheel 1835 Mar 12 2015 rlstdc.h > -rw-r--r-- 1 root wheel 3046 Mar 12 2015 tilde.h > -rw-r--r-- 1 root wheel 10079 Mar 12 2015 history.h > -rw-r--r-- 1 root wheel 3163 Mar 12 2015 keymaps.h > -rw-r--r-- 1 root wheel 4577 Mar 12 2015 chardefs.h > -rw-r--r-- 1 root wheel 37802 Mar 12 2015 readline.h but "pkg which" reports those files as being from readline-6.3.8 . I guess I can just delete would would normally have been = /usr/local/include/iconv.h . Back to quoting the earlier message: > We likely just need to prioritize /usr/include over /usr/local/include > for these phases, which gcc49 may have backwards since it has its = prefix > set to /usr/local from the ports build. >=20 >>>> # find /usr/include/ -exec grep dwarf_errmsg {} \; -print >>>> #define dwarf_errmsg(error) dwarf_errmsg_(&error) >>>> const char *dwarf_errmsg_(Dwarf_Error *); >>>> /usr/include/libdwarf.h >>>> # find /usr/local/include/ -exec grep dwarf_errmsg {} \; -print >>>> char* dwarf_errmsg(Dwarf_Error /*error*/); >>>> /usr/local/include/renamed_libdwarf.h >>>> # >> So dwarf_errmsg is from /usr/local/include and dwarf_errmsg_ is from = /usr/include . >>=20 >> The failure shows references to dwarf_errmsg instead of dwarf_errmsg_ = --and dwarf_errmsg being undefined (dwarf_errno has similar issues): >>=20 >>>> -------------------------------------------------------------- >>>>>>>>>> stage 3: cross tools >>>> -------------------------------------------------------------- >>>> . . . >>>> --- ctfconvert.full --- >>>> /usr/local/bin/gcc49 -O2 -pipe = -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/includ= e -I/usr/src/cddl/usr.b >>>> in/ctfconvert/../../../cddl/contrib/opensolaris = -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris = -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head = -I/us >>>> = r/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/= common >>> = -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools= /ctf/cvt >>> -I/usr/src/cddl/usr.bin/ctfconvert/. >>>> ./../../sys/cddl/contrib/opensolaris/uts/common = -DNEED_SOLARIS_BOOLEAN -g -std=3Dgnu99 = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include = -static -L/usr/obj/xtoolchain/powerpc.power >>>> pc64/usr/src/tmp/legacy/usr/lib -o ctfconvert.full alist.o ctf.o = ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o = memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol >>>> .o tdata.o traverse.o util.o -ldwarf -lelf -lelf -lz = -lpthread -legacy >>>> dwarf.o: In function `die_off': >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:270: undefined reference to `dwarf_errmsg' >>>> dwarf.o: In function `die_sibling': >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:288: undefined reference to `dwarf_errmsg' >>>> dwarf.o: In function `die_child': >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:305: undefined reference to `dwarf_errmsg' >>>> dwarf.o: In function `die_tag': >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:319: undefined reference to `dwarf_errmsg' >>>> dwarf.o: In function `die_unsigned': >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:370: undefined reference to `dwarf_errmsg' >>>> = dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris= /tools/ctf/cvt/dwarf.c:418: more undefined references to `dwarf_errmsg' = follow >>>> dwarf.o: In function `dw_read': >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:1963: undefined reference to `dwarf_errno' >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:1971: undefined reference to `dwarf_errmsg' >>>> = /usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/c= tf/cvt/dwarf.c:1977: undefined reference to `dwarf_errmsg' >>>> collect2: error: ld returned 1 exit status >>>> *** [ctfconvert.full] Error code 1 >>=20 >=20 >=20 > --=20 > Regards, > Bryan Drewery =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Mar 31 22:34:43 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 AA9F8AE4556; Thu, 31 Mar 2016 22:34:43 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 98ACF1236; Thu, 31 Mar 2016 22:34:43 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 888051668; Thu, 31 Mar 2016 22:34:43 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 35E291FD7E; Thu, 31 Mar 2016 22:34:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id H2VrfZ_ogwaq; Thu, 31 Mar 2016 22:34:34 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 5EDF31FD79 To: Mark Millard References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer From: Bryan Drewery Organization: FreeBSD Message-ID: <56FDA5F9.1090601@FreeBSD.org> Date: Thu, 31 Mar 2016 15:34:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Thu, 31 Mar 2016 22:34:43 -0000 On 3/31/16 3:02 PM, Mark Millard wrote: >> > We likely just need to prioritize /usr/include over /usr/local/inclu= de >> > for these phases, which gcc49 may have backwards since it has its pr= efix >> > set to /usr/local from the ports build. Yup this is the problem with using the ports compiler as the "host" compiler: > # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/gcc49 > COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc49/gcc/x86_64-portbld-freeb= sd11.0/4.9.4/lto-wrapper > Target: x86_64-portbld-freebsd11.0 > Configured with: ./../gcc-4.9-20160210/configure --with-build-config=3D= bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=3D/= usr/local/lib/gcc49 --libexecdir=3D/usr/local/libexec/gcc49 --program-suf= fix=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/b= in/ld --with-pkgversion=3D'FreeBSD Ports Collection' --with-system-zlib -= -with-ecj-jar=3D/usr/local/share/java/ecj-4.5.jar --enable-languages=3Dc,= c++,objc,fortran,java --prefix=3D/usr/local --localstatedir=3D/var --mand= ir=3D/usr/local/man --infodir=3D/usr/local/info/gcc49 --build=3Dx86_64-po= rtbld-freebsd11.0 > Thread model: posix > gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection) > COLLECT_GCC_OPTIONS=3D'-v' '-o' '/dev/null' '-mtune=3Dgeneric' '-march=3D= x86-64' > /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus = -quiet -v - -quiet -dumpbase - -mtune=3Dgeneric -march=3Dx86-64 -auxbase = - -version -o /tmp//ccA75yFy.s > GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) = (x86_64-portbld-freebsd11.0) > compiled by GNU C version 4.9.4 20160210 (prerelease), GMP vers= ion 5.1.3, MPFR version 3.1.3, MPC version 1.0.3 > GGC heuristics: --param ggc-min-expand=3D100 --param ggc-min-heapsize=3D= 131072 > ignoring nonexistent directory "/usr/local/lib/gcc49/gcc/x86_64-portbld= -freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc49/include/c++/ > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 > /usr/local/lib/gcc49/include/c++//backward > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include > /usr/local/include > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixe= d > /usr/include > End of search list. Note the /usr/local/include and /usr/include order near the end. Passing -isystem /usr/include seems to fix it: > # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null -isystem /usr/= include > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/gcc49 > COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc49/gcc/x86_64-portbld-freeb= sd11.0/4.9.4/lto-wrapper > Target: x86_64-portbld-freebsd11.0 > Configured with: ./../gcc-4.9-20160210/configure --with-build-config=3D= bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=3D/= usr/local/lib/gcc49 --libexecdir=3D/usr/local/libexec/gcc49 --program-suf= fix=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/b= in/ld --with-pkgversion=3D'FreeBSD Ports Collection' --with-system-zlib -= -with-ecj-jar=3D/usr/local/share/java/ecj-4.5.jar --enable-languages=3Dc,= c++,objc,fortran,java --prefix=3D/usr/local --localstatedir=3D/var --mand= ir=3D/usr/local/man --infodir=3D/usr/local/info/gcc49 --build=3Dx86_64-po= rtbld-freebsd11.0 > Thread model: posix > gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection) > COLLECT_GCC_OPTIONS=3D'-v' '-o' '/dev/null' '-isystem' '/usr/include' '= -mtune=3Dgeneric' '-march=3Dx86-64' > /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus = -quiet -v -isystem /usr/include - -quiet -dumpbase - -mtune=3Dgeneric -ma= rch=3Dx86-64 -auxbase - -version -o /tmp//ccNh006Z.s > GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 (prerelease) = (x86_64-portbld-freebsd11.0) > compiled by GNU C version 4.9.4 20160210 (prerelease), GMP vers= ion 5.1.3, MPFR version 3.1.3, MPC version 1.0.3 > GGC heuristics: --param ggc-min-expand=3D100 --param ggc-min-heapsize=3D= 131072 > ignoring nonexistent directory "/usr/local/lib/gcc49/gcc/x86_64-portbld= -freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include" > ignoring duplicate directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/include > /usr/local/lib/gcc49/include/c++/ > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 > /usr/local/lib/gcc49/include/c++//backward > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include > /usr/local/include > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixe= d 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. 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 Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Thu Mar 31 22:44:56 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 0782DAE48A5 for ; Thu, 31 Mar 2016 22:44:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7EE91717 for ; Thu, 31 Mar 2016 22:44:55 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-pf0-x234.google.com with SMTP id x3so79234340pfb.1 for ; Thu, 31 Mar 2016 15:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:from:in-reply-to:date:cc:message-id :references:to; bh=lQBZCPII2YTXOYAlvMYJfMEsFWDdNzv89moekgKXmfw=; b=Z3jaRpgFHK89Jp/YNRs8K0SmQvN7AfOCZJQkCHLAtcIS2jysJ1/VSgqema26vWlV7G fqCh1ns7mx6OHgnSeGCBDiaNGRaxT9Lk14b5BBIDI6t52wWNgbb0z1ZmvnEIh3iFsBCL Fh0b6ovw2LRA/L/dgzu3VQtWT6kO8LKo9qBFk1r0IOemanV/2/VxLNEw+ThvpQaMp/// NWCWOViPK3gdfskoqyEvChUXAk85albwBE3N9GH+os0VoHymbqQ8fezmwcg0Ln9Z9XVb ql8Cnkrh1oWCcwwSFXhBL+n04H1wYyU/LAjFMXby7C8PgSQZEnEBQ3HrbZBzNiEAmeNV c++Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:from:in-reply-to :date:cc:message-id:references:to; bh=lQBZCPII2YTXOYAlvMYJfMEsFWDdNzv89moekgKXmfw=; b=Zge03Pk4vxPzwiFSQobiTN6CRi/ZshfvyrlvC/GE5MTJmSa8Y/O04oDA1/6STuDhNm GUb38UrBFVkcGyTXYQjvOs+9Q7M3NZQEc9ACWAo83FLVQoGb+/3k9qjlB0zC1GZYrPJk +pwK+hqnSA07sUNDaz8hzT5KOqUGz2ToMDlAABbeBH33jmWBpT2/K66wCUjXI7vKDVNX WXvVJiY7tleT+K9zzN4M2nF/VgFbfgnPEYlc6p6xTTnAcI0uJiF9CVc+AfUnRD2ryF34 5YHhyuaygRsY1x0Kp5ZQawuR3f7l7VsdbQO1jwW/rV7D3ZiSVXUDKm/nkt5aPefyVCuU FWrQ== X-Gm-Message-State: AD7BkJJnS8woVsDu2wN4D/gQSbplklNLKkvHz8iwW6GZ1jN9hzQWeGW/0TRsWV82Vxf9OQ== X-Received: by 10.98.67.199 with SMTP id l68mr25387181pfi.18.1459464295103; Thu, 31 Mar 2016 15:44:55 -0700 (PDT) Received: from [100.127.5.59] ([69.53.245.84]) by smtp.gmail.com with ESMTPSA id ql1sm15748412pac.24.2016.03.31.15.44.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 15:44:54 -0700 (PDT) Sender: Warner Losh Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_29365E74-707B-47CB-9B7C-C91B946C1F86"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <56FDA5F9.1090601@FreeBSD.org> Date: Thu, 31 Mar 2016 16:44:51 -0600 Cc: Mark Millard , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML , FreeBSD Toolchain 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> To: Bryan Drewery X-Mailer: Apple Mail (2.2104) 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: Thu, 31 Mar 2016 22:44:56 -0000 --Apple-Mail=_29365E74-707B-47CB-9B7C-C91B946C1F86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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. 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. > 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. /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. Warner --Apple-Mail=_29365E74-707B-47CB-9B7C-C91B946C1F86 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW/ahkAAoJEGwc0Sh9sBEA7o0P/imn/bPGIed9K9AcFYRgb37H SaG3d38dv0BfOKbLF18ZdgsxT+SCNjlbEodnaF0WQl9Z5yROomXTzB/iu41XbsCg EpgtY9ziJQkYVX4esJEgvcYdCtNbIS1LAt2vxQOaxCf+5eV5ZpRppp7h0LUFZdK4 ypHo9pIUjCeNlUp39Fvyg4lHVZiMe+T8utSYvn2AiLorJ9THDwCwyrVIXBcm+vyu 1Q6vaNsqH8X9bZMfCZ5jX8xd4lUAdsOSbJVh7mXYf6FKyuQlfJDkP3V/2I+7klNY o9U9fejq1fT4sL7d5tJMjF4+qkSU1Lwpck17NXoEFH9XfmNhz1gIJBiJ8UwXvy7M dt2G/DyDZpvEuc5eWQVuov0RF1m1zLV5S1qhqoOsgecjqfhoX4mDYv+w2jr6R6/3 Q8cFezAYmbA3hmrxcDEWzTin5JKsLEROjx88o1y3wxF0x3ZMaR6ZCJI38bpn2KEy eIWC3iBXdyXTmMGIETQzBwjToZEH/Bjhvlw0hn8ZwBpWH4l6+Sv/JKZ+1cfZa1F5 mjpLlDI+M2E9bhlIa6ovMmNdP0sQsm49i7zKyT6UZXs2hNsKJ1JxhX6DXQu3Nxa9 Rxi7PufO8SouKK5AIjtfbqI6B8mW/bvLkjcBNwYefLbb7pM/82RU/nPgjgciDeh4 yqAXuf4R5st8THHR9y+H =lG36 -----END PGP SIGNATURE----- --Apple-Mail=_29365E74-707B-47CB-9B7C-C91B946C1F86-- From owner-freebsd-toolchain@freebsd.org Thu Mar 31 23:42:51 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 2CC5EAE4AE1 for ; Thu, 31 Mar 2016 23:42:51 +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 E0C371E63 for ; Thu, 31 Mar 2016 23:42:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26951 invoked from network); 31 Mar 2016 23:42:46 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 23:42:46 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 19:42:52 -0400 (EDT) Received: (qmail 8083 invoked from network); 31 Mar 2016 23:42:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Mar 2016 23:42:52 -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 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 E758B1C4078; Thu, 31 Mar 2016 16:42:42 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 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: <56FDA5F9.1090601@FreeBSD.org> Date: Thu, 31 Mar 2016 16:42:47 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@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> To: 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: Thu, 31 Mar 2016 23:42:51 -0000 On 2016-Mar-31, at 3:34 PM, Bryan Drewery = wrote: > #include "..." search starts here: > #include <...> search starts here: > /usr/local/lib/gcc49/include/c++/ > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 > /usr/local/lib/gcc49/include/c++//backward > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include > /usr/local/include > = /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed > /usr/include > End of search list. Beyond /usr/local/include is also the fun of [ignoring C++ specific = issues]: (My quoting of a copy/paste) > # ls = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include* > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include: > altivec.h iso646.h ppc-asm.h = spu2vmx.h stdatomic.h stdint-gcc.h = unwind.h > float.h objc ppu_intrinsics.h = ssp stdbool.h stdint.h = varargs.h > htmintrin.h omp.h si2vmx.h = stdalign.h stddef.h stdnoreturn.h = vec_types.h > htmxlintrin.h paired.h spe.h = stdarg.h stdfix.h tgmath.h >=20 > = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= : > README libmilter limits.h netinet = stddef.h stdio.h stdlib.h sys = syslimits.h unistd.h wchar.h But at least in recent times after WCHAR_TYPE was fixed for = powerpc/powerpc64 I've not had troubles that traced to these for CC and = CXX being based on gcc49 while XCC and XCXX were based on powerpc64-gcc = for buildworld/buildkernel on a powerpc64 host. I have had various examples of /usr/local/include/ files breaking builds = depending on what ports were in place at the time. All along I've been = doing renaming in that area to allow buildworld/buildkernel use. =3D=3D=3D Mark Millard markmi at dsl-only.net Message history: On 2016-Mar-31, at 3:34 PM, Bryan Drewery = wrote: >=20 > On 3/31/16 3:02 PM, Mark Millard wrote: >>>> We likely just need to prioritize /usr/include over = /usr/local/include >>>> for these phases, which gcc49 may have backwards since it has its = prefix >>>> set to /usr/local from the ports build. >=20 > Yup this is the problem with using the ports compiler as the "host" > compiler: >=20 >> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null >> Using built-in specs. >> COLLECT_GCC=3D/usr/local/bin/gcc49 >> = COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd1= 1.0/4.9.4/lto-wrapper >> Target: x86_64-portbld-freebsd11.0 >> Configured with: ./../gcc-4.9-20160210/configure = --with-build-config=3Dbootstrap-debug --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 = --with-ecj-jar=3D/usr/local/share/java/ecj-4.5.jar = --enable-languages=3Dc,c++,objc,fortran,java --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc49 --build=3Dx86_64-portbld-freebsd11.0 >> Thread model: posix >> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection) >> COLLECT_GCC_OPTIONS=3D'-v' '-o' '/dev/null' '-mtune=3Dgeneric' = '-march=3Dx86-64' >> /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus = -quiet -v - -quiet -dumpbase - -mtune=3Dgeneric -march=3Dx86-64 -auxbase = - -version -o /tmp//ccA75yFy.s >> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 = (prerelease) (x86_64-portbld-freebsd11.0) >> compiled by GNU C version 4.9.4 20160210 (prerelease), GMP = version 5.1.3, MPFR version 3.1.3, MPC version 1.0.3 >> GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 >> ignoring nonexistent directory = "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../= x86_64-portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc49/include/c++/ >> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 >> /usr/local/lib/gcc49/include/c++//backward >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include >> /usr/local/include >> = /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed >> /usr/include >> End of search list. >=20 > Note the /usr/local/include and /usr/include order near the end. >=20 > Passing -isystem /usr/include seems to fix it: >=20 >> # echo '' |/usr/local/bin/gcc49 -v -x c++ - -o /dev/null -isystem = /usr/include >> Using built-in specs. >> COLLECT_GCC=3D/usr/local/bin/gcc49 >> = COLLECT_LTO_WRAPPER=3D/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd1= 1.0/4.9.4/lto-wrapper >> Target: x86_64-portbld-freebsd11.0 >> Configured with: ./../gcc-4.9-20160210/configure = --with-build-config=3Dbootstrap-debug --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 = --with-ecj-jar=3D/usr/local/share/java/ecj-4.5.jar = --enable-languages=3Dc,c++,objc,fortran,java --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/gcc49 --build=3Dx86_64-portbld-freebsd11.0 >> Thread model: posix >> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection) >> COLLECT_GCC_OPTIONS=3D'-v' '-o' '/dev/null' '-isystem' '/usr/include' = '-mtune=3Dgeneric' '-march=3Dx86-64' >> /usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/cc1plus = -quiet -v -isystem /usr/include - -quiet -dumpbase - -mtune=3Dgeneric = -march=3Dx86-64 -auxbase - -version -o /tmp//ccNh006Z.s >> GNU C++ (FreeBSD Ports Collection) version 4.9.4 20160210 = (prerelease) (x86_64-portbld-freebsd11.0) >> compiled by GNU C version 4.9.4 20160210 (prerelease), GMP = version 5.1.3, MPFR version 3.1.3, MPC version 1.0.3 >> GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 >> ignoring nonexistent directory = "/usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../= x86_64-portbld-freebsd11.0/include" >> ignoring duplicate directory "/usr/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/include >> /usr/local/lib/gcc49/include/c++/ >> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 >> /usr/local/lib/gcc49/include/c++//backward >> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include >> /usr/local/include >> = /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed >=20 > 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 > 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 >=20 >=20 > --=20 > Regards, > Bryan Drewery >=20 From owner-freebsd-toolchain@freebsd.org Fri Apr 1 00:02:54 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 C3D4CAE537C; Fri, 1 Apr 2016 00:02:54 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B137219DA; Fri, 1 Apr 2016 00:02:54 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id A871812B3; Fri, 1 Apr 2016 00:02:54 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 610BC1FE99; Fri, 1 Apr 2016 00:02:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Ii1SnVmNmSay; Fri, 1 Apr 2016 00:02:51 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 38D731FE92 To: Mark Millard 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> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh From: Bryan Drewery Organization: FreeBSD Message-ID: <56FDBAA8.5060407@FreeBSD.org> Date: Thu, 31 Mar 2016 17:02:48 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Fri, 01 Apr 2016 00:02:54 -0000 On 3/31/16 4:42 PM, Mark Millard wrote: > On 2016-Mar-31, at 3:34 PM, Bryan Drewery wrote: >> > #include "..." search starts here: >> > #include <...> search starts here: >> > /usr/local/lib/gcc49/include/c++/ >> > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 >> > /usr/local/lib/gcc49/include/c++//backward >> > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include >> > /usr/local/include >> > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed >> > /usr/include >> > End of search list. > Beyond /usr/local/include is also the fun of [ignoring C++ specific issues]: > (My quoting of a copy/paste) > >> > # ls /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include* >> > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include: >> > altivec.h iso646.h ppc-asm.h spu2vmx.h stdatomic.h stdint-gcc.h unwind.h >> > float.h objc ppu_intrinsics.h ssp stdbool.h stdint.h varargs.h >> > htmintrin.h omp.h si2vmx.h stdalign.h stddef.h stdnoreturn.h vec_types.h >> > htmxlintrin.h paired.h spe.h stdarg.h stdfix.h tgmath.h >> > >> > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed: >> > README libmilter limits.h netinet stddef.h stdio.h stdlib.h sys syslimits.h unistd.h wchar.h > But at least in recent times after WCHAR_TYPE was fixed for powerpc/powerpc64 I've not had troubles that traced to these for CC and CXX being based on gcc49 while XCC and XCXX were based on powerpc64-gcc for buildworld/buildkernel on a powerpc64 host. > > I have had various examples of /usr/local/include/ files breaking builds depending on what ports were in place at the time. All along I've been doing renaming in that area to allow buildworld/buildkernel use. This should be fine with my fix too. Trying add this to your make.conf for now: CFLAGS.gcc+= -isystem /usr/include -- Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Fri Apr 1 00:17:44 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 AB0FBAE5781 for ; Fri, 1 Apr 2016 00:17:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 6E8351029 for ; Fri, 1 Apr 2016 00:17:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2209 invoked from network); 1 Apr 2016 00:17:40 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 00:17:40 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 20:17:47 -0400 (EDT) Received: (qmail 28075 invoked from network); 1 Apr 2016 00:17:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 00:17:46 -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 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 3E6CF1C4075; Thu, 31 Mar 2016 17:17:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 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: <56FDBAA8.5060407@FreeBSD.org> Date: Thu, 31 Mar 2016 17:17:41 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <82792F3C-6F9A-49CD-8C64-27CDF9DFBAB7@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> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> To: 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: Fri, 01 Apr 2016 00:17:44 -0000 On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: > This should be fine with my fix too. >=20 > Trying add this to your make.conf for now: >=20 > CFLAGS.gcc+=3D -isystem /usr/include I'll try that. But just FYI: here are the lists of files from gcc49 that = having /usr/include first will change what gcc49 sets up for itself and = has been using in my past activities (spanning both 4.9.4/include/ and = 4.9.4/include-fixed/ ): > # diff -rq /usr/include/ = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ | = grep "^Files " > Files /usr/include/float.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/float= .h differ > Files /usr/include/iso646.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/iso64= 6.h differ > Files /usr/include/ssp/ssp.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/s= sp.h differ > Files /usr/include/ssp/stdio.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/s= tdio.h differ > Files /usr/include/ssp/string.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/s= tring.h differ > Files /usr/include/ssp/unistd.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/ssp/u= nistd.h differ > Files /usr/include/stdalign.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdal= ign.h differ > Files /usr/include/stdarg.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdar= g.h differ > Files /usr/include/stdatomic.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdat= omic.h differ > Files /usr/include/stdbool.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdbo= ol.h differ > Files /usr/include/stddef.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdde= f.h differ > Files /usr/include/stdint.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdin= t.h differ > Files /usr/include/stdnoreturn.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/stdno= return.h differ > Files /usr/include/tgmath.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/tgmat= h.h differ > Files /usr/include/varargs.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include/varar= gs.h differ > # diff -rq /usr/include/ = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= / | grep "^Files " > Files /usr/include/libmilter/mfapi.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /libmilter/mfapi.h differ > Files /usr/include/limits.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /limits.h differ > Files /usr/include/netinet/ip_fil.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /netinet/ip_fil.h differ > Files /usr/include/netinet/ip_lookup.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /netinet/ip_lookup.h differ > Files /usr/include/netinet/ip_nat.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /netinet/ip_nat.h differ > Files /usr/include/netinet/ip_proxy.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /netinet/ip_proxy.h differ > Files /usr/include/netinet/ip_scan.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /netinet/ip_scan.h differ > Files /usr/include/netinet/ip_state.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /netinet/ip_state.h differ > Files /usr/include/stddef.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /stddef.h differ > Files /usr/include/stdio.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /stdio.h differ > Files /usr/include/stdlib.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /stdlib.h differ > Files /usr/include/sys/types.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /sys/types.h differ > Files /usr/include/unistd.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /unistd.h differ > Files /usr/include/wchar.h and = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= /wchar.h differ =3D=3D=3D Mark Millard markmi@dsl-only.net On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote: On 3/31/16 4:42 PM, Mark Millard wrote: > On 2016-Mar-31, at 3:34 PM, Bryan Drewery = wrote: >>> #include "..." search starts here: >>> #include <...> search starts here: >>> /usr/local/lib/gcc49/include/c++/ >>> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 >>> /usr/local/lib/gcc49/include/c++//backward >>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include >>> /usr/local/include >>> = /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed >>> /usr/include >>> End of search list. > Beyond /usr/local/include is also the fun of [ignoring C++ specific = issues]: > (My quoting of a copy/paste) >=20 >>> # ls = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include* >>> = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include: >>> altivec.h iso646.h ppc-asm.h = spu2vmx.h stdatomic.h stdint-gcc.h = unwind.h >>> float.h objc ppu_intrinsics.h = ssp stdbool.h stdint.h = varargs.h >>> htmintrin.h omp.h si2vmx.h = stdalign.h stddef.h stdnoreturn.h = vec_types.h >>> htmxlintrin.h paired.h spe.h = stdarg.h stdfix.h tgmath.h >>>=20 >>> = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= : >>> README libmilter limits.h netinet = stddef.h stdio.h stdlib.h sys = syslimits.h unistd.h wchar.h > But at least in recent times after WCHAR_TYPE was fixed for = powerpc/powerpc64 I've not had troubles that traced to these for CC and = CXX being based on gcc49 while XCC and XCXX were based on powerpc64-gcc = for buildworld/buildkernel on a powerpc64 host. >=20 > I have had various examples of /usr/local/include/ files breaking = builds depending on what ports were in place at the time. All along I've = been doing renaming in that area to allow buildworld/buildkernel use. This should be fine with my fix too. Trying add this to your make.conf for now: CFLAGS.gcc+=3D -isystem /usr/include --=20 Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Fri Apr 1 03:14:25 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 0BEC2AE45F5 for ; Fri, 1 Apr 2016 03:14:25 +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 C372616C3 for ; Fri, 1 Apr 2016 03:14:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 788 invoked from network); 1 Apr 2016 03:14:45 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 03:14:45 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 23:14:13 -0400 (EDT) Received: (qmail 2458 invoked from network); 1 Apr 2016 03:14:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 03:14: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 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 3DD6C1C4075; Thu, 31 Mar 2016 20:14:16 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 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: <56FDBAA8.5060407@FreeBSD.org> Date: Thu, 31 Mar 2016 20:14:21 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <7DEF97EC-D970-4F64-AF72-8939609A1D48@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> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> To: 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: Fri, 01 Apr 2016 03:14:25 -0000 On 2016-Mar-31, at 5:02 PM, Bryan Drewery = wrote: > This should be fine with my fix too. >=20 > Trying add this to your make.conf for now: >=20 > CFLAGS.gcc+=3D -isystem /usr/include [Context note: I normally use: > WITHOUT_CROSS_COMPILER=3D > # > WITH_FAST_DEPEND=3D > WITH_LIBCPLUSPLUS=3D > WITH_BOOT=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_LLDB=3D so clang is built by powerpc64-gcc's tools even though clang is not used = for the build. ] The result was almost immediate build failure: > --- _bootstrap-tools-lib/clang/libllvmsupport --- > --- APFloat.o --- > In file included from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/AlignOf.h:19:0, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/S= mallVector.h:18, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/Allocator.h:24, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/S= tringMap.h:18, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/Host.h:17, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/H= ashing.h:49, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= rrayRef.h:13, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= PInt.h:19, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= PFloat.h:20, > from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp:15: > /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: '::max_align_t' = has not been declared > using ::max_align_t; ^ =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Mar-31, at 5:02 PM, Bryan Drewery = wrote: > On 3/31/16 4:42 PM, Mark Millard wrote: >> On 2016-Mar-31, at 3:34 PM, Bryan Drewery = wrote: >>>> #include "..." search starts here: >>>> #include <...> search starts here: >>>> /usr/local/lib/gcc49/include/c++/ >>>> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 >>>> /usr/local/lib/gcc49/include/c++//backward >>>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include >>>> /usr/local/include >>>> = /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed >>>> /usr/include >>>> End of search list. >> Beyond /usr/local/include is also the fun of [ignoring C++ specific = issues]: >> (My quoting of a copy/paste) >>=20 >>>> # ls = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include* >>>> = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include: >>>> altivec.h iso646.h ppc-asm.h = spu2vmx.h stdatomic.h stdint-gcc.h = unwind.h >>>> float.h objc ppu_intrinsics.h = ssp stdbool.h stdint.h = varargs.h >>>> htmintrin.h omp.h si2vmx.h = stdalign.h stddef.h stdnoreturn.h = vec_types.h >>>> htmxlintrin.h paired.h spe.h = stdarg.h stdfix.h tgmath.h >>>>=20 >>>> = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= : >>>> README libmilter limits.h netinet = stddef.h stdio.h stdlib.h sys = syslimits.h unistd.h wchar.h >> But at least in recent times after WCHAR_TYPE was fixed for = powerpc/powerpc64 I've not had troubles that traced to these for CC and = CXX being based on gcc49 while XCC and XCXX were based on powerpc64-gcc = for buildworld/buildkernel on a powerpc64 host. >>=20 >> I have had various examples of /usr/local/include/ files breaking = builds depending on what ports were in place at the time. All along I've = been doing renaming in that area to allow buildworld/buildkernel use. >=20 > This should be fine with my fix too. >=20 > Trying add this to your make.conf for now: >=20 > CFLAGS.gcc+=3D -isystem /usr/include >=20 --=20 Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Fri Apr 1 03:33:11 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 AD7B0AE4D29 for ; Fri, 1 Apr 2016 03:33:11 +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 7079A13DE for ; Fri, 1 Apr 2016 03:33:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1119 invoked from network); 1 Apr 2016 03:33:31 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 03:33:31 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.1) with SMTP; Thu, 31 Mar 2016 23:33:32 -0400 (EDT) Received: (qmail 12225 invoked from network); 1 Apr 2016 03:33:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 03:33:31 -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 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 41F111C4075; Thu, 31 Mar 2016 20:33:03 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 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: <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> Date: Thu, 31 Mar 2016 20:33:08 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh 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> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> To: 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: Fri, 01 Apr 2016 03:33:11 -0000 On 2016-Mar-31, at 8:14 PM, Mark Millard wrote: >=20 > On 2016-Mar-31, at 5:02 PM, Bryan Drewery = wrote: >=20 >> This should be fine with my fix too. >>=20 >> Trying add this to your make.conf for now: >>=20 >> CFLAGS.gcc+=3D -isystem /usr/include >=20 > [Context note: I normally use: >=20 >> WITHOUT_CROSS_COMPILER=3D >> # >> WITH_FAST_DEPEND=3D >> WITH_LIBCPLUSPLUS=3D >> WITH_BOOT=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_LLDB=3D >=20 >=20 > so clang is built by powerpc64-gcc's tools even though clang is not = used for the build. > ] >=20 > The result was almost immediate build failure: >=20 >> --- _bootstrap-tools-lib/clang/libllvmsupport --- >> --- APFloat.o --- >> In file included from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/AlignOf.h:19:0, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/S= mallVector.h:18, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/Allocator.h:24, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/S= tringMap.h:18, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Suppo= rt/Host.h:17, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/H= ashing.h:49, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= rrayRef.h:13, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= PInt.h:19, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/A= PFloat.h:20, >> from = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloa= t.cpp:15: >> /usr/local/lib/gcc49/include/c++/cstddef:51:11: error: = '::max_align_t' has not been declared >> using ::max_align_t; > ^ >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I added using -v in CFLAGS.gcc in order for it to report include search = paths. The last one of reported in the script output looks like: > ignoring nonexistent directory = "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../= ../powerpc64-portbld-freebsd11.0/include" > ignoring duplicate directory "/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include > = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/includ= e > /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support > . > = /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/in= clude > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include > /usr/include > /usr/local/lib/gcc49/include/c++/ > /usr/local/lib/gcc49/include/c++//powerpc64-portbld-freebsd11.0 > /usr/local/lib/gcc49/include/c++//backward > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include > /usr/local/include > = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= > End of search list. I appears that C++ needs its own override for where to find C++ header = before looking in the gcc49 specific places. These sorts of odd, hard to avoid dependencies are part of why I asked = if there was a standard/recommend assignment to use for CC/XCC: I was = hoping there was a known-good way to compile that avoided the issues, = possibly by using powerpc64-gcc tools for CC/XCC as well. FYI: The last C compile in this script output lists: > ignoring nonexistent directory = "/usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/../../../../= ../powerpc64-portbld-freebsd11.0/include" > ignoring duplicate directory "/usr/include" > ignoring duplicate directory = "/usr/src/kerberos5/tools/make-roken/../../include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/kerberos5/tools/make-roken/../../include > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/legacy/usr/include > /usr/include > /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include > /usr/local/include > = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= > End of search list. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Mar-31, at 5:02 PM, Bryan Drewery = wrote: > On 3/31/16 4:42 PM, Mark Millard wrote: >> On 2016-Mar-31, at 3:34 PM, Bryan Drewery = wrote: >>>> #include "..." search starts here: >>>> #include <...> search starts here: >>>> /usr/local/lib/gcc49/include/c++/ >>>> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0 >>>> /usr/local/lib/gcc49/include/c++//backward >>>> /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include >>>> /usr/local/include >>>> = /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed >>>> /usr/include >>>> End of search list. >> Beyond /usr/local/include is also the fun of [ignoring C++ specific = issues]: >> (My quoting of a copy/paste) >>=20 >>>> # ls = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include* >>>> = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include: >>>> altivec.h iso646.h ppc-asm.h = spu2vmx.h stdatomic.h stdint-gcc.h = unwind.h >>>> float.h objc ppu_intrinsics.h = ssp stdbool.h stdint.h = varargs.h >>>> htmintrin.h omp.h si2vmx.h = stdalign.h stddef.h stdnoreturn.h = vec_types.h >>>> htmxlintrin.h paired.h spe.h = stdarg.h stdfix.h tgmath.h >>>>=20 >>>> = /usr/local/lib/gcc49/gcc/powerpc64-portbld-freebsd11.0/4.9.4/include-fixed= : >>>> README libmilter limits.h netinet = stddef.h stdio.h stdlib.h sys = syslimits.h unistd.h wchar.h >> But at least in recent times after WCHAR_TYPE was fixed for = powerpc/powerpc64 I've not had troubles that traced to these for CC and = CXX being based on gcc49 while XCC and XCXX were based on powerpc64-gcc = for buildworld/buildkernel on a powerpc64 host. >>=20 >> I have had various examples of /usr/local/include/ files breaking = builds depending on what ports were in place at the time. All along I've = been doing renaming in that area to allow buildworld/buildkernel use. >=20 > This should be fine with my fix too. >=20 > Trying add this to your make.conf for now: >=20 > CFLAGS.gcc+=3D -isystem /usr/include >=20 --=20 Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Fri Apr 1 08:25:31 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 42E76AE301B; Fri, 1 Apr 2016 08:25:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1C861089; Fri, 1 Apr 2016 08:25:30 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::5dfd:8cdd:f0f4:ff76] (unknown [IPv6:2001:7b8:3a7:0:5dfd:8cdd:f0f4:ff76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8F5107074; Fri, 1 Apr 2016 10:25:27 +0200 (CEST) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A95B8F40-09B8-483E-B4C8-EA591BCA8042"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: Date: Fri, 1 Apr 2016 10:25:21 +0200 Cc: Bryan Drewery , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML , Mark Millard Message-Id: <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> 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> To: Warner Losh 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: Fri, 01 Apr 2016 08:25:31 -0000 --Apple-Mail=_A95B8F40-09B8-483E-B4C8-EA591BCA8042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. 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... :) >> 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. 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. 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. -Dimitry --Apple-Mail=_A95B8F40-09B8-483E-B4C8-EA591BCA8042 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlb+MHkACgkQsF6jCi4glqNjHgCgsJZMqs4Te2EV2NDcadXNc8ps miUAoPSWYhEHQHgVem89zyv2uzETotf7 =Q3vy -----END PGP SIGNATURE----- --Apple-Mail=_A95B8F40-09B8-483E-B4C8-EA591BCA8042-- From owner-freebsd-toolchain@freebsd.org Fri Apr 1 14:25:25 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 A9CE6AEB4A8 for ; Fri, 1 Apr 2016 14:25:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76C4B1951 for ; Fri, 1 Apr 2016 14:25:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id q128so150868001iof.3 for ; Fri, 01 Apr 2016 07:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=ztcpeWmxeXvDy1B2jwK/EMrAtztvPo6Dy8umTYIOtVI=; b=QiLU4d7K8buq1pwv9QhnKxh4t2VcTQy03nRuMlALFJiOA9Dc76rQLvXq2bC8Ku6EXV wOZqq/h0Z3enPngJzAAto/1apd5QyyZ2LXPgqATkgqYLf08K3NDsWqCUB0Pm4/rYLoGW ibvyYJKxHe/2GqtD0YSCfr90YfkRCaoIfFcm72tcp9OTbLs1zd8Q4C2x6oMl7eRM8D8o F6zja00NxnFzFHyL5auyBEIv4eJWlACf96pgMWgWaR7ytHG3B8HgDWZmoV9PtKncsxnt GeyKpdi42/acl6YFmxbw2Lc9kyDgK118olRMzsBPfyK+DLrtLL9ICWsiVBYLq/B5t7iD ewDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ztcpeWmxeXvDy1B2jwK/EMrAtztvPo6Dy8umTYIOtVI=; b=INqx8SPwPlz8aTdd7pw38QCdS1toGQ39x12w2sSLo1TDmL8hRyJ8CqXNnCYDgiwXbC sCmA0XBKD2uiQlgf6t8axL2aVZEvOMyvuexLP8H509w1eORfdEymR67D+3tijhQm4FE5 lduTV4t32VnwVPziq++SEzsALwedhHCFSJbit9EMFNjXPXzdtoLokHZXziBgVGoXwg4P MVFcATVz8BYfozRXhQ/SRs937aIzYvGCePfhda3HUy3dHXYEasoQN8G/WYo1ypeTd0vP zRmYxKXXrNuimyQOPi9phCOAmVx405lDfYE3GxEMq9e/v9JbEXz52HGf/Ys5RDzz62k6 DWPg== X-Gm-Message-State: AD7BkJL5JHAe0uOomaVqzyw6TVPaAj7J6jbLaYELQtzquh7v/2aL8fdjIgYMtbuVgfYTCKgCmOlvH/kjtlumgw== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr4703129ioe.135.1459520724863; Fri, 01 Apr 2016 07:25:24 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.194.3 with HTTP; Fri, 1 Apr 2016 07:25:24 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> 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> Date: Fri, 1 Apr 2016 08:25:24 -0600 X-Google-Sender-Auth: 4dKbIK7UyA631kxSL2aolgvrY_A Message-ID: Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Warner Losh To: Dimitry Andric Cc: Bryan Drewery , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML , Mark Millard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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: Fri, 01 Apr 2016 14:25:25 -0000 On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric wrote: > On 01 Apr 2016, at 00:44, Warner Losh wrote: > > > >> 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. > > > > It has for a while now. It=E2=80=99s one of the maddening inconsistenci= es 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. > > 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... :) That's why it shouldn't be *FIRST*, not why it shouldn't be there at all. >> 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 wi= sh > >> /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. > > > > /usr/include should be first. But it isn=E2=80=99t. That=E2=80=99s anot= her inconsistency > that was found > > when we looked at /usr/local stuff. Someone recently added > /usr/local/bin to the path, > > if I recall correctly. > > 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. > 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. > 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. 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. Warner From owner-freebsd-toolchain@freebsd.org Fri Apr 1 22:52:37 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 93338AEC5F4; Fri, 1 Apr 2016 22:52:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8324D174D; Fri, 1 Apr 2016 22:52:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 7B5451B00; Fri, 1 Apr 2016 22:52:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 479442111A; Fri, 1 Apr 2016 22:52:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id UH2XqgjaCBRe; Fri, 1 Apr 2016 22:52:35 +0000 (UTC) Subject: Re: 11.0 -r297369: _el_fn_sh_complete missing in buildworld; /usr/obj/. . ./lib/libedit/ has no filecomplete.* DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com BC3BF21114 To: Mark Millard , FreeBSD PowerPC ML , FreeBSD Current , FreeBSD Toolchain References: <97E93CA6-3F0A-47C8-BAE6-1B6866EED3CB@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <56FEFBB2.2050001@FreeBSD.org> Date: Fri, 1 Apr 2016 15:52:34 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <97E93CA6-3F0A-47C8-BAE6-1B6866EED3CB@dsl-only.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Fri, 01 Apr 2016 22:52:37 -0000 On 3/29/16 6:35 PM, Mark Millard wrote: > Going from 11.0-CURRENT -r297048 to -r297369: buildworld after svnlite update: > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/. . . ends up with no filecomplete.* > but the build tries to use what would be some of its contents (_el_fn_sh_complete) > > The details. . . FYI this was fixed in r297435. -- Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Fri Apr 1 23:35:35 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 5C74FB00110 for ; Fri, 1 Apr 2016 23:35:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 0D41B16B0 for ; Fri, 1 Apr 2016 23:35:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6822 invoked from network); 1 Apr 2016 23:35:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 23:35:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.2) with SMTP; Fri, 01 Apr 2016 19:35:18 -0400 (EDT) Received: (qmail 15716 invoked from network); 1 Apr 2016 23:35:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Apr 2016 23:35:18 -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 47B391C42BD; Fri, 1 Apr 2016 16:35:22 -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: Fri, 1 Apr 2016 16:35:26 -0700 Cc: Dimitry Andric , Bryan Drewery , FreeBSD Toolchain , FreeBSD Current , Gerald Pfeifer , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <5334F356-982F-40CA-9009-41B59AAC8665@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> To: Warner Losh 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: Fri, 01 Apr 2016 23:35:35 -0000 [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: > > > >> 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. > > > > 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. > > > > /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 =20 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