From owner-freebsd-toolchain@freebsd.org Sun Jun 25 00:55:11 2017 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 58467DA8C32 for ; Sun, 25 Jun 2017 00:55:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (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 1CA457DDF0 for ; Sun, 25 Jun 2017 00:55:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3881 invoked from network); 25 Jun 2017 00:59:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Jun 2017 00:59:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sat, 24 Jun 2017 20:55:08 -0400 (EDT) Received: (qmail 22288 invoked from network); 25 Jun 2017 00:55:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Jun 2017 00:55:08 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AEB10EC86E7; Sat, 24 Jun 2017 17:55:07 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work Message-Id: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> Date: Sat, 24 Jun 2017 17:55:07 -0700 Cc: Pedro Giffuni , Gerald Pfeifer To: re@FreeBSD.org, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 25 Jun 2017 00:55:11 -0000 The following is based mostly on an extraction from a private exchange in which a question was asked and my answer was unsettling: incompatibilities within the 11.* family. I would not normally send to re but doing so was explicitly mentioned. Hopefully this example is reasonable for doing that. Aspect #0: what is broken currently (and in the future?) within the 11.* family? lang/gcc* packages built on release/11.0.1/ to not work fully on stable/11/ or on the drafts of release/11.1.0/ . (I leave releng/11.*/'s implicit.) -r313194 in head and was describied with: > Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >=20 > The types are for the byte offset and page index in vm object. They > are similar to off_t, which is defined as 64bit MI integer. Using MI > definitions will allow to provide consistent MD values of vm > object-related maximum sizes. The known issue is the generation of header dependencies in the lang/gcc* builds on release/11.0.1/ that when used on stable/11/ or release/11.0.1/ generate reports like: = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:266:9: error: '__vm_ooffset_t' does not name a type typedef __vm_ooffset_t vm_ooffset_t; ^ = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:268:9: error: '__vm_pindex_t' does not name a type typedef __vm_pindex_t vm_pindex_t; ^ *** [CoinFactorization2.lo] Error code 1 Unfortunately UPDATING was not updated for head/'s -r313194 (2017-Feb-4) --nor for stable/11/'s -r313574 (2017-Feb-11), the MFC. (No MFC was made to stable/10/ or to release/10.3.0 as far as I found.) (These changes predate the INO64 issue in head/ . Head ends up with more issues than I'm dealing with here.) Aspect #1: what 11.* version builds the pre-built packages targeting 11.* and the apparent consequences (given the vm_ooffset_t and vm_pindex_t changes and the lang/gcc* build behavior) This is the unsettling part for pre-built packages: incompatibilities within the 11.* family for the lang/gcc* packages. = http://portsmon.freebsd.org/portoverview.py?category=3D%3Bamng&portname=3D= gcc5&wildcard=3D shows categories for builds for 8.4 9.3 10.1 10.3 11.0 head (Nothing for stable/*/ .) But the 10.3 rows show no package builds. I would guess that they start once 10.1 stops (approximately). So it may be that 11.1 will not get package builds until 11.0 stops (approximately). If so unless lang/gcc* are changed to bootstrap differently they will configure to match release/11.0.1/ and will not be compatible with the vm_ooffset_t and vm_pindex_t changes in stable/11/ and release/11.1.0/ . But as I understand updating how the lang/gcc* builds work to remove such dependencies is under investigation. I do not know any timing relative to release/11.1.0/ if my understanding is right. Until then (if I was right): Unless there are separate packages made for targeting release/11.0.1/ vs. release/11.1.0/ it is not obvious when lang/gcc* packages will be generally compatible with various folks choices about what to install as the system version within the release/11.*/ and stable/11/ family. This would likely be true even if they were built on release/11.1.0/ : then release/11.0.1/ likely would have compatibility problems. The ABI versioning does not cover the specific issues involved based on how vm_ooffset_t and vm_pindex_t were changed and what the lang/gcc* builds do relative to such changes. Yet there is incompatibility for some fairly-significant-usage ports. Aspect #2: stable/10/ and release/10.4.0/ Just covered for completeness: I do not see a MFC of -r313194 to stable/10/ : its sys/sys/types.h dates back to 2015-Oct-10. So it looks like 10.x has a permanent difference in this area: 10.x continues to get separate lang/gcc* package builds from 11.x and later. No problem for this context as far as I know. Note: To simplify I choose to not be explicit about what authors wrote what original text. If that becomes an issue, it is correctable. Blame me for any errors in the above. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Jun 25 21:13:58 2017 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 A894DD9A861 for ; Sun, 25 Jun 2017 21:13:58 +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 963F57E471 for ; Sun, 25 Jun 2017 21:13:58 +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 v5PLDwmM038598 for ; Sun, 25 Jun 2017 21:13:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220184] clang 4.0.0 segfaults on buildworld Date: Sun, 25 Jun 2017 21:13:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: chrysalis@chrysalisnet.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.23 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, 25 Jun 2017 21:13:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220184 --- Comment #18 from Chris Collins --- Ok a further update. After a reboot, the i5 750 machine started getting segfaults again, a few reboots later I have discovered the behaviour is fairly consistent, where a rolld o the dice occurs on a reboot, usually if the first buildworld has no problem I can probably do 3+ in a row with no segfault, but if the first ha= s a segfault then I will struggle to get just one successful buildworld. I discovered the LAPIC timer on my laptop is broken, aided by a warning on = the console, when I switched it to i8254 the problem stopped. I then fresh installed 11.0 again and discovered on 11.0 it uses i8254 by default but on 11-STABLE it uses LAPIC, when LAPIC is used I see some other odd behaviours e.g. systat -v 1 will update really slowly. I then checked on my i5 750 on 11.0 it uses LAPIC by default and seems to w= ork ok, on 11-STABLE LAPIC has the same issues as the laptop and it defaults to HPET. At the time of this post I havent tried a buildworld using a non def= ault timer, but I am running buildworld now using i8254 on the i5 750 to see what results I get, I will run many times over multiple reboots. The VMWare hypervisor has no segfault problems and uses LAPIC by default working fine on 11.0 and 11-STABLE. All the current tests are with empty src.conf aside from 'LOADER_ZFS_SUPPORT=3DYES'' and no CPUTYPE defined to try and simplify the diagnosis. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jun 25 21:15:34 2017 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 C152ED9A888 for ; Sun, 25 Jun 2017 21:15:34 +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 AF81C7E4AD for ; Sun, 25 Jun 2017 21:15:34 +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 v5PLFXfE083627 for ; Sun, 25 Jun 2017 21:15:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220184] clang 4.0.0 segfaults on buildworld Date: Sun, 25 Jun 2017 21:15:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: chrysalis@chrysalisnet.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.23 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, 25 Jun 2017 21:15:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220184 --- Comment #19 from Chris Collins --- So to confirm as I dont think I written it well, using i8254 on my laptop I dont get segfaults. The default timer changed between 11.0 and 11-STABLE. I also meant "roll of the dice" but typod. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Jun 25 21:52:03 2017 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 22F91D9B18A for ; Sun, 25 Jun 2017 21:52:03 +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 0C06D7F12D for ; Sun, 25 Jun 2017 21:52:03 +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 v5PLq2sQ089001 for ; Sun, 25 Jun 2017 21:52:02 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220184] clang 4.0.0 segfaults on buildworld Date: Sun, 25 Jun 2017 21:52:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.23 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, 25 Jun 2017 21:52:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220184 --- Comment #20 from Mark Millard --- (In reply to Chris Collins from comments #18 and #19) Interesting --and non-obvious. >From what I've read Message Signaled Interrupts (MSI) from PCI 2.2+ depend on LAPIC, requiring LAPIC to be enabled. If LAPIC is not working correctly then MSI might not work fully correctly either and so should be avoided in such a context? (I'm not familiar with the details in this area. Take the above as hear-say.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jun 26 15:01:39 2017 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 6DB5AD896C5 for ; Mon, 26 Jun 2017 15:01:39 +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 5BD3F7C7AA for ; Mon, 26 Jun 2017 15:01:39 +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 v5QF1cs1068406 for ; Mon, 26 Jun 2017 15:01:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220184] clang 4.0.0 segfaults on buildworld Date: Mon, 26 Jun 2017 15:01:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: chrysalis@chrysalisnet.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:01:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220184 --- Comment #21 from Chris Collins --- No issues on the i5 750 now as well across 4 reboots and 13 buildworlds. I may raise a new bug regarding the timers, as I had to as well adjust the timecounter on my laptop to get C states working, its default kept it in C1= all the time, so seems is weird eventtimer and timecounter issues on older hardware. The VMWare machine which has no is is a 2016 cpu. The i5 750 cpu was released in 2009 The laptop cpu is a core 2 duo T5750 released in 2008 Thanks guys for your help. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jun 26 15:06:17 2017 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 9166AD89759 for ; Mon, 26 Jun 2017 15:06:17 +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 7FCC87C900 for ; Mon, 26 Jun 2017 15:06:17 +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 v5QF6Hme003128 for ; Mon, 26 Jun 2017 15:06:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 220184] clang 4.0.0 segfaults on buildworld Date: Mon, 26 Jun 2017 15:06:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: chrysalis@chrysalisnet.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:06:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220184 --- Comment #22 from Chris Collins --- (In reply to Mark Millard from comment #20) Thanks, the laptop isnt using MSIX, or MSI anyway so I am ok on that, I will have a look at the i5 750 dmesg to see if MSI or MSIX is used. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Jun 26 19:12:31 2017 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 2936AD8EBEA for ; Mon, 26 Jun 2017 19:12:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 D7F08849CB for ; Mon, 26 Jun 2017 19:12:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27928 invoked from network); 26 Jun 2017 19:05:49 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 Jun 2017 19:05:49 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 26 Jun 2017 15:05:49 -0400 (EDT) Received: (qmail 11654 invoked from network); 26 Jun 2017 19:05:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jun 2017 19:05:48 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0DF63EC86E7; Mon, 26 Jun 2017 12:05:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work From: Mark Millard In-Reply-To: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> Date: Mon, 26 Jun 2017 12:05:47 -0700 Cc: FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni , Gerald Pfeifer Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> To: papowell@astart.com X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 19:12:31 -0000 Top post on one point. . . Patrick Powell papowell at astart.com wrote on Mon Jun 26 14:10:44 UTC = 2017 (He was quoting Gerald. I was also part of some earlier discussions.) > (Luckily this only hits with most -CURRENT versions of FreeBSD and > older packages only.) >=20 > Gerald Unfortunately this part is false if it is about the vm_ooffset_t and vm_pindex_t issue: stable/11/ and release/11.1.0/ also have the vm_ooffset_t and vm_pindex_t issue vs. lang/gcc* packages built by release/11.0.1/ . The issue is not limited to head (12) at this point: Installing a gcc* package built by release/11.0.1/ fails now for stable/11/ and the drafs oft release/11.1.0/ . Anyone progressing to one of those has to build the lang/gcc* of interest from source under the newer system context. (Mixing source builds and package builds is discouraged as I understand.) I'm not claiming which specific handling needs to be made. But the vm_ooffset_t and vm_pindex_t changes did not even make the UPDATING notes. Right now things look to have the worst combination for lang/gcc* when release/11.1.0/ becomes official: lang/gcc* 's break without notification or suggestion of a workaround. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jun-24, at 5:55 PM, Mark Millard wrote: The following is based mostly on an extraction from a private exchange in which a question was asked and my answer was unsettling: incompatibilities within the 11.* family. I would not normally send to re but doing so was explicitly mentioned. Hopefully this example is reasonable for doing that. Aspect #0: what is broken currently (and in the future?) within the 11.* family? lang/gcc* packages built on release/11.0.1/ to not work fully on stable/11/ or on the drafts of release/11.1.0/ . (I leave releng/11.*/'s implicit.) -r313194 in head and was describied with: > Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >=20 > The types are for the byte offset and page index in vm object. They > are similar to off_t, which is defined as 64bit MI integer. Using MI > definitions will allow to provide consistent MD values of vm > object-related maximum sizes. The known issue is the generation of header dependencies in the lang/gcc* builds on release/11.0.1/ that when used on stable/11/ or release/11.0.1/ generate reports like: = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:266:9: error: '__vm_ooffset_t' does not name a type typedef __vm_ooffset_t vm_ooffset_t; ^ = /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys= /types.h:268:9: error: '__vm_pindex_t' does not name a type typedef __vm_pindex_t vm_pindex_t; ^ *** [CoinFactorization2.lo] Error code 1 Unfortunately UPDATING was not updated for head/'s -r313194 (2017-Feb-4) --nor for stable/11/'s -r313574 (2017-Feb-11), the MFC. (No MFC was made to stable/10/ or to release/10.3.0 as far as I found.) (These changes predate the INO64 issue in head/ . Head ends up with more issues than I'm dealing with here.) Aspect #1: what 11.* version builds the pre-built packages targeting 11.* and the apparent consequences (given the vm_ooffset_t and vm_pindex_t changes and the lang/gcc* build behavior) This is the unsettling part for pre-built packages: incompatibilities within the 11.* family for the lang/gcc* packages. = http://portsmon.freebsd.org/portoverview.py?category=3D%3Bamng&portname=3D= gcc5&wildcard=3D shows categories for builds for 8.4 9.3 10.1 10.3 11.0 head (Nothing for stable/*/ .) But the 10.3 rows show no package builds. I would guess that they start once 10.1 stops (approximately). So it may be that 11.1 will not get package builds until 11.0 stops (approximately). If so unless lang/gcc* are changed to bootstrap differently they will configure to match release/11.0.1/ and will not be compatible with the vm_ooffset_t and vm_pindex_t changes in stable/11/ and release/11.1.0/ . But as I understand updating how the lang/gcc* builds work to remove such dependencies is under investigation. I do not know any timing relative to release/11.1.0/ if my understanding is right. Until then (if I was right): Unless there are separate packages made for targeting release/11.0.1/ vs. release/11.1.0/ it is not obvious when lang/gcc* packages will be generally compatible with various folks choices about what to install as the system version within the release/11.*/ and stable/11/ family. This would likely be true even if they were built on release/11.1.0/ : then release/11.0.1/ likely would have compatibility problems. The ABI versioning does not cover the specific issues involved based on how vm_ooffset_t and vm_pindex_t were changed and what the lang/gcc* builds do relative to such changes. Yet there is incompatibility for some fairly-significant-usage ports. Aspect #2: stable/10/ and release/10.4.0/ Just covered for completeness: I do not see a MFC of -r313194 to stable/10/ : its sys/sys/types.h dates back to 2015-Oct-10. So it looks like 10.x has a permanent difference in this area: 10.x continues to get separate lang/gcc* package builds from 11.x and later. No problem for this context as far as I know. Note: To simplify I choose to not be explicit about what authors wrote what original text. If that becomes an issue, it is correctable. Blame me for any errors in the above. =3D=3D=3D Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@freebsd.org Mon Jun 26 23:30:34 2017 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 47A28D94317 for ; Mon, 26 Jun 2017 23:30:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 D7D856EED0 for ; Mon, 26 Jun 2017 23:30:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2725 invoked from network); 26 Jun 2017 23:30:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Jun 2017 23:30:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 26 Jun 2017 19:30:31 -0400 (EDT) Received: (qmail 8925 invoked from network); 26 Jun 2017 23:30:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Jun 2017 23:30:31 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1B8B2EC893D; Mon, 26 Jun 2017 16:30:31 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320192 -> -r320387 kernel build and install to a DESTDIR: if_igb.ko vs. DESTDIR use for installkernel has symbolic link that seems inapproriate Message-Id: <4176FEB2-192E-4204-8F74-598CB74B1132@dsl-only.net> Date: Mon, 26 Jun 2017 16:30:30 -0700 To: FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 23:30:34 -0000 installkernel = DESTDIR=3D/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387 produced a if_igb.ko (this used: ls -lD %C ): lrwxr-xr-x 1 root wheel 80 20 if_igb.ko -> = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _em.ko This does not allow simple copies of such directory trees that have if_igb.ko pointing to the right if_em.ko. Looking in my -r320192 based /boot/kernel/ that had been filled in via a default DESTDIR for installkernel (this used: ls -lD %C ): lrwxr-xr-x 1 root wheel 21 20 if_igb.ko -> = /boot/kernel/if_em.ko So something like: cp -aRx /boot/kernel/ /boot/kercgd ends up with /boot/kercgd/if_igb.ko pointing into /boot/kernel/ instead of into /boot/kercgd/ . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Jun 27 03:11:27 2017 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 566F7D9C483 for ; Tue, 27 Jun 2017 03:11:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 1A96876B0D for ; Tue, 27 Jun 2017 03:11:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6607 invoked from network); 27 Jun 2017 03:11:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Jun 2017 03:11:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 26 Jun 2017 23:11:25 -0400 (EDT) Received: (qmail 28370 invoked from network); 27 Jun 2017 03:11:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 27 Jun 2017 03:11:25 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5F0B3EC894C; Mon, 26 Jun 2017 20:11:24 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Recent reports of needing to avoid META_MODE for head kernel builds for updates: a preliminary investigation Message-Id: <5D970E60-5F3A-4580-9E7F-5CFD96361546@dsl-only.net> Date: Mon, 26 Jun 2017 20:11:23 -0700 To: Bryan Drewery , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 27 Jun 2017 03:11:27 -0000 For an example of the recent reports: David Wolfskill david at catwhisker.org wrote on Mon Jun 26 12:44:20 UTC 2017 : > On Mon, Jun 26, 2017 at 03:29:59PM +0300, Konstantin Belousov wrote: > > ... > > > > Hmmm..... > > > > As if computer tries to say you, do not use meta mode. >=20 >=20 > For building the kernel, on head as of some commit after r320307 (but > by r320324). While there are other kernel issues going on I decided to try to investigate the difference in meta mode incremental build results vs. full rebuild. I started with head -r320192. This sequence avoids updating the live kernel (since other problems are being looked into). Local DESTDIR's are used for installkernel. # more ~/src.configs/src.conf.amd64-clang.amd64-host=20 TO_TYPE=3Damd64 # KERNCONF=3DGENERIC-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # #WITH_CROSS_COMPILER=3D WITH_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D #WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITHOUT_LLD_IS_LD=3D WITH_LLVM_LIBUNWIND=3D WITH_LLDB=3D #PORTS_MODULES=3Demulators/virtualbox-ose-additions # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D Note the "WITH_REPRODUCIBLE_BUILD=3D". =46rom a -r320192 context I did: svnlite update -r320387 /usr/src I then used my usual script to do buildworld buildkernel. It updated = things in the pre-existing /usr/obj/amd64_clang/amd64.amd64/ . (I cause the explicit amd64.amd64 deliberately. This is not a cross build.) I'll note that I've been using /usr/obj/amd64_clang/amd64.amd64/ for incremental builds for a long time. (This will show up later.) I then used the script to: installkernel = DESTDIR=3D/usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387 I then moved /usr/obj/amd64_clang/ to be /usr/obj/amd64_clang_192_387/ = for later potential detailed comparisons. I then redid the buildworld = buildkernel=20 which produced another /usr/obj/amd64_clang/ but from scratch this time. I then used the script to: installkernel = DESTDIR=3D/usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387 I then did (the D %C avoids date/time text being different): # ls -lD %C = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ = > ~/ls_192_387_kernel.txt # ls -lD %C = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ = > ~/ls_noth_387_kernel.txt allowing me to compare sizes and permissions: # diff -u ~/ls_192_387_kernel.txt ~/ls_noth_387_kernel.txt | more --- /root/ls_192_387_kernel.txt 2017-06-26 16:13:25.734588000 -0700 +++ /root/ls_noth_387_kernel.txt 2017-06-26 18:22:34.001866000 = -0700 @@ -1,4 +1,4 @@ -total 69163 +total 68995 -r-xr-xr-x 1 root wheel 107664 20 aac.ko -r-xr-xr-x 1 root wheel 105232 20 aacraid.ko -r-xr-xr-x 1 root wheel 6296 20 accf_data.ko @@ -270,7 +270,7 @@ -r-xr-xr-x 1 root wheel 41968 20 if_gre.ko -r-xr-xr-x 1 root wheel 41664 20 if_hme.ko -r-xr-xr-x 1 root wheel 18192 20 if_ic.ko -lrwxr-xr-x 1 root wheel 80 20 if_igb.ko -> = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _em.ko +lrwxr-xr-x 1 root wheel 80 20 if_igb.ko -> = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _em.ko -r-xr-xr-x 1 root wheel 24000 20 if_ipheth.ko -r-xr-xr-x 1 root wheel 78344 20 if_ipw.ko -r-xr-xr-x 1 root wheel 113544 20 if_iwi.ko @@ -419,7 +419,7 @@ -r-xr-xr-x 1 root wheel 12160 20 joy.ko -r-xr-xr-x 1 root wheel 46984 20 kbdmux.ko -r-xr-xr-x 1 root wheel 14168 20 kern_testfrwk.ko --r-xr-xr-x 1 root wheel 27479832 20 kernel +-r-xr-xr-x 1 root wheel 27307184 20 kernel -r-xr-xr-x 1 root wheel 105216 20 kgssapi.ko -r-xr-xr-x 1 root wheel 53840 20 kgssapi_krb5.ko -r-xr-xr-x 1 root wheel 163976 20 krpc.ko [Note: there is still a problem of if_igb.ko being handled as a full-pathj symbolic link such that copying kernels around=20 need not end up with a working if_igb.ko . I doubt that this is the problem that the reports are about.] The kernel from the incremental build is larger (includes more?). Of this the kernel being a different size would seem to be a problem. But going in a different direction that is more detailed (content comparison spanning all of boot, not just boot/kernel/ ): # diff -r = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/ = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/ | more Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ae= sni.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ae= sni.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/at= h_hal_ar5416.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/at= h_hal_ar5416.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ca= m.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ca= m.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/dt= race.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/dt= race.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/fa= sttrap.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/fa= sttrap.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ge= om_raid.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ge= om_raid.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ge= om_raid3.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ge= om_raid3.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _de.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _de.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _jme.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _jme.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _mxge.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _mxge.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _oce.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _oce.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _qlnxe.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _qlnxe.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _qlxge.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _qlxge.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _vr.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _vr.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/if= _vtnet.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/if= _vtnet.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ip= fw.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ip= fw.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ip= l.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ip= l.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ke= rnel and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ke= rnel differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/kr= pc.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/kr= pc.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/li= nker.hints and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/li= nker.hints differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/li= nux.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/li= nux.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/li= nux64.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/li= nux64.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/nf= scommon.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/nf= scommon.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/nf= sd.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/nf= sd.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/ng= _ksocket.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/ng= _ksocket.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/pf= .ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/pf= .ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/sn= d_emu10kx.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/sn= d_emu10kx.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/sy= svmsg.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/sy= svmsg.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/t4= _tom.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/t4= _tom.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/wl= an.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/wl= an.ko differ Binary files = /usr/obj/DESTDIRs/clang-amd64-installkernel-r320192_r320387/boot/kernel/zf= s.ko and = /usr/obj/DESTDIRs/clang-amd64-installkernel-nothing_r320387/boot/kernel/zf= s.ko differ So a fair number of .ko files also end up being different by content for a from-scratch build, not just kernel . Going through looking at .o files for size and permissions. . . --- /root/ls_192_387_sys_o.txt 2017-06-26 16:54:32.669034000 -0700 +++ /root/ls_noth_387_sys_o.txt 2017-06-26 18:24:19.604302000 -0700 (So "+" is the from-scratch build again.) Some are different in size (just a couple of examples are shown of the many): --rw-r--r-- 1 root wheel 310240 20 ./GENERIC-NODBG/aacraid.o +-rw-r--r-- 1 root wheel 310264 20 ./GENERIC-NODBG/aacraid.o --rw-r--r-- 1 root wheel 128960 20 ./GENERIC-NODBG/ar9280_olc.o +-rw-r--r-- 1 root wheel 128976 20 ./GENERIC-NODBG/ar9280_olc.o Looking also at dates for the above (and any other name matches): aacraid.o . . . /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 310240 = Jun 19 22:38:55 2017 ./GENERIC-NODBG/aacraid.o /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 283504 = Jun 26 15:56:22 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/aacraid/aacraid.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 310264 = Jun 26 18:20:07 2017 ./GENERIC-NODBG/aacraid.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 283504 = Jun 26 18:16:44 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/aacraid/aacraid.o So for the incremental upgrade the module's aacraid.o was rebuilt but the non-module one was not updated. ar9280_olc.o . . . /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 128960 = Jun 19 22:39:42 2017 ./GENERIC-NODBG/ar9280_olc.o /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 128984 = May 3 02:38:30 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ar9280_olc.o /root/ls_192_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 129000 = Jun 26 15:56:36 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath_hal_ar5416/ar9280_olc.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 128976 = Jun 26 18:20:16 2017 ./GENERIC-NODBG/ar9280_olc.o /root/ls_noth_387_sys_o_with_date.txt:-rw-r--r-- 1 root wheel 129024 = Jun 26 18:16:57 2017 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath_hal_ar5416/ar9280_olc.o In this last case the number of files does not match: the "May 3" is extra. Again the module's .o was updated by the incremental build but the non-module one was not. Some exist only in the -r320192 -> -r320387 incremental build: (some omitted but incremental builds seem to not clean out old .o's from prior buildkernel activity in general) --rw-r--r-- 1 root wheel 46992 20 ./GENERIC-NODBG/amd64_mem.o --rw-r--r-- 1 root wheel 4176 20 ./GENERIC-NODBG/eisa_if.o --rw-r--r-- 1 root wheel 27064 20 ./GENERIC-NODBG/hv_heartbeat.o --rw-r--r-- 1 root wheel 87368 20 ./GENERIC-NODBG/hv_net_vsc.o --rw-r--r-- 1 root wheel 278712 20 = ./GENERIC-NODBG/hv_netvsc_drv_freebsd.o --rw-r--r-- 1 root wheel 101920 20 ./GENERIC-NODBG/hv_rndis_filter.o --rw-r--r-- 1 root wheel 27704 20 ./GENERIC-NODBG/hv_shutdown.o --rw-r--r-- 1 root wheel 38008 20 ./GENERIC-NODBG/hv_timesync.o --rw-r--r-- 1 root wheel 24640 20 ./GENERIC-NODBG/hv_util.o --rw-r--r-- 1 root wheel 590520 20 ./GENERIC-NODBG/if_igb.o --rw-r--r-- 1 root wheel 465848 20 ./GENERIC-NODBG/if_lem.o --rw-r--r-- 1 root wheel 86488 20 ./GENERIC-NODBG/ip_ipsec.o --rw-r--r-- 1 root wheel 153472 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah.o --rw-r--r-- 1 root wheel 99056 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_9287.o --rw-r--r-- 1 root wheel 90416 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_v1.o --rw-r--r-- 1 root wheel 100608 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_v14.o --rw-r--r-- 1 root wheel 151288 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/ah_eeprom_v3.o . . . --rw-r--r-- 1 root wheel 245592 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/if_ath_tx_edma.o --rw-r--r-- 1 root wheel 226432 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/if_ath_tx_ht.o --rw-r--r-- 1 root wheel 289928 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ath/sample.o --rw-r--r-- 1 root wheel 18440 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_nvram.o --rw-r--r-- 1 root wheel 161840 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_nvram_common.o --rw-r--r-- 1 root wheel 67320 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_nvram_parser.o --rw-r--r-- 1 root wheel 40488 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_sprom_parser.o --rw-r--r-- 1 root wheel 34728 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/bhnd_sprom_subr.o --rw-r--r-- 1 root wheel 31976 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/cores/bhnd_chipc/bhnd_spr= om_chipc.o --rw-r--r-- 1 root wheel 115256 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/cores/bhnd_chipc/chipc.o --rw-r--r-- 1 root wheel 46264 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/cores/bhnd_chipc/chipc_su= br.o --rw-r--r-- 1 root wheel 133560 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/bhnd/nvram_subr.o --rw-r--r-- 1 root wheel 247344 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/ctl/ctl_frontend_iscsi.o --rw-r--r-- 1 root wheel 162408 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/cxgbe/cxgbei/cxgbei_ulp2_ddp.o= --rw-r--r-- 1 root wheel 174752 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_dma.o --rw-r--r-- 1 root wheel 120016 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_drv.o --rw-r--r-- 1 root wheel 141880 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_irq.o --rw-r--r-- 1 root wheel 134000 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_mem.o --rw-r--r-- 1 root wheel 136912 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/i915/i915_suspend.o --rw-r--r-- 1 root wheel 208104 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/r300_cmdbuf.o --rw-r--r-- 1 root wheel 174912 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/r600_blit.o --rw-r--r-- 1 root wheel 339512 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/r600_cp.o --rw-r--r-- 1 root wheel 245632 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_cp.o --rw-r--r-- 1 root wheel 156736 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_cs.o --rw-r--r-- 1 root wheel 140072 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_drv.o --rw-r--r-- 1 root wheel 139608 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_irq.o --rw-r--r-- 1 root wheel 129824 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_mem.o --rw-r--r-- 1 root wheel 352464 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/drm/radeon/radeon_state.o --rw-r--r-- 1 root wheel 816 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/dtrace/dtrace/assym.o --rw-r--r-- 1 root wheel 430976 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/em/if_lem.o --rw-r--r-- 1 root wheel 117376 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/en/if_en_pci.o --rw-r--r-- 1 root wheel 236040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/en/midway.o --rw-r--r-- 1 root wheel 282368 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/fatm/if_fatm.o --rw-r--r-- 1 root wheel 83520 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/geom/geom_part/geom_part_pc98/= g_part_pc98.o --rw-r--r-- 1 root wheel 310872 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm.o --rw-r--r-- 1 root wheel 93040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_intr.o --rw-r--r-- 1 root wheel 77992 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_ioctl.o --rw-r--r-- 1 root wheel 77784 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_rx.o --rw-r--r-- 1 root wheel 151736 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hatm/if_hatm_tx.o --rw-r--r-- 1 root wheel 86872 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/netvsc/hv_net_vsc.o --rw-r--r-- 1 root wheel 243992 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/netvsc/hv_netvsc_drv_fr= eebsd.o --rw-r--r-- 1 root wheel 101480 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/netvsc/hv_rndis_filter.= o --rw-r--r-- 1 root wheel 27240 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_heartbeat.= o --rw-r--r-- 1 root wheel 27880 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_shutdown.o= --rw-r--r-- 1 root wheel 38184 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_timesync.o= --rw-r--r-- 1 root wheel 24824 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/hyperv/utilities/hv_util.o --rw-r--r-- 1 root wheel 125184 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_80003es2lan.o --rw-r--r-- 1 root wheel 78984 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82540.o --rw-r--r-- 1 root wheel 95856 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82541.o --rw-r--r-- 1 root wheel 69624 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82542.o --rw-r--r-- 1 root wheel 125888 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82543.o --rw-r--r-- 1 root wheel 166040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82571.o --rw-r--r-- 1 root wheel 240320 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_82575.o --rw-r--r-- 1 root wheel 91168 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_api.o --rw-r--r-- 1 root wheel 96536 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_i210.o --rw-r--r-- 1 root wheel 342880 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_ich8lan.o --rw-r--r-- 1 root wheel 167104 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_mac.o --rw-r--r-- 1 root wheel 76168 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_manage.o --rw-r--r-- 1 root wheel 82936 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_mbx.o --rw-r--r-- 1 root wheel 100096 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_nvm.o --rw-r--r-- 1 root wheel 52456 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_osdep.o --rw-r--r-- 1 root wheel 177672 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_phy.o --rw-r--r-- 1 root wheel 59088 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/e1000_vf.o --rw-r--r-- 1 root wheel 554784 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/igb/if_igb.o --rw-r--r-- 1 root wheel 50496 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/mcd/mcd_isa.o --rw-r--r-- 1 root wheel 47072 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/mem/amd64_mem.o --rw-r--r-- 1 root wheel 26888 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/mmcsd/mmc_subr.o --rw-r--r-- 1 root wheel 55000 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/msdosfs/msdosfs_fileno.o --rw-r--r-- 1 root wheel 142248 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm.o --rw-r--r-- 1 root wheel 152064 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_attach.o --rw-r--r-- 1 root wheel 102056 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_intr.o --rw-r--r-- 1 root wheel 75560 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_ioctl.o --rw-r--r-- 1 root wheel 40592 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_rtables.o --rw-r--r-- 1 root wheel 107744 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_rx.o --rw-r--r-- 1 root wheel 167912 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/patm/if_patm_tx.o --rw-r--r-- 1 root wheel 19080 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/rtwnfw/rtwnrtl8192cUB/rtwn-rtl= 8192cfwU_B.o --rw-r--r-- 1 root wheel 96288 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/scd/scd.o --rw-r--r-- 1 root wheel 49512 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/scd/scd_isa.o --rw-r--r-- 1 root wheel 96376 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/sfxge/efx_wol.o --rw-r--r-- 1 root wheel 80552 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/sfxge/hunt_phy.o --rw-r--r-- 1 root wheel 75160 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si.o --rw-r--r-- 1 root wheel 11952 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si2_z280.o --rw-r--r-- 1 root wheel 24904 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si3_t225.o --rw-r--r-- 1 root wheel 37416 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si_isa.o --rw-r--r-- 1 root wheel 33280 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/si/si_pci.o --rw-r--r-- 1 root wheel 617464 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwn/if_urtwn.o --rw-r--r-- 1 root wheel 18136 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwnfw/urtwnrtl8188eu/urtwn-r= tl8188eufw.o --rw-r--r-- 1 root wheel 18136 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwnfw/urtwnrtl8192cT/urtwn-r= tl8192cfwT.o --rw-r--r-- 1 root wheel 18136 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/urtwnfw/urtwnrtl8192cU/urtwn-r= tl8192cfwU.o --rw-r--r-- 1 root wheel 55040 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/utopia/idtphy.o --rw-r--r-- 1 root wheel 53400 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/utopia/suni.o --rw-r--r-- 1 root wheel 123216 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/utopia/utopia.o --rw-r--r-- 1 root wheel 12952 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/vmm/amdv.o --rw-r--r-- 1 root wheel 204240 20 = ./GENERIC-NODBG/modules/usr/src/sys/modules/zfs/gfs.o --rw-r--r-- 1 root wheel 54880 20 ./GENERIC-NODBG/msdosfs_fileno.o --rw-r--r-- 1 root wheel 75480 20 ./GENERIC-NODBG/nvme_all.o --rw-r--r-- 1 root wheel 125568 20 ./GENERIC-NODBG/nvme_xpt.o --rw-r--r-- 1 root wheel 82296 20 ./GENERIC-NODBG/procfs_ctl.o --rw-r--r-- 1 root wheel 77320 20 ./GENERIC-NODBG/vm_unix.o --rw-r--r-- 1 root wheel 892 20 ./boot/geli/explicit_bzero.o (The somewhat manual process might have put a few extra lines above.) If any of this is picked up and linked in to kernel it might explain part of the kernel file size difference: 27479832 - 27307184 =3D=3D 172648 . I stop with this for now. It seems that as things are that one should clean out the buildkernel materials at least for some types of build contexts before doing another buildkernel. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Jun 28 10:23:49 2017 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 23DA5D9E408; Wed, 28 Jun 2017 10:23:49 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (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 E558373560; Wed, 28 Jun 2017 10:23:48 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (localhost [127.0.0.1]) by ainaz.pair.com (Postfix) with ESMTP id 686653F56A; Wed, 28 Jun 2017 06:23:41 -0400 (EDT) Received: from [192.168.1.109] (unknown [202.188.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 811703F569; Wed, 28 Jun 2017 06:23:24 -0400 (EDT) Date: Wed, 28 Jun 2017 18:21:59 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work To: Mark Millard ,papowell@astart.com CC: FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni , Gerald Pfeifer From: Gerald Pfeifer Message-ID: <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 28 Jun 2017 10:23:49 -0000 Hi everyone, I am testing a patch for gcc5-devel right now that will disable fixinclude= s (or rather its fixed files) being packaged=2E Should that work fine for you, I will push this back to gcc5 the following= days=2E That said, the change that triggered this is what I would expect on CURREN= T, not STABLE (and hence hoped we'd have more time for this change)=2E My Internet connectivity right now is only slightly above pigeon speed, so= sorry for any delays=2E Gerald From owner-freebsd-toolchain@freebsd.org Wed Jun 28 14:45:36 2017 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 47BD3DA3A5B for ; Wed, 28 Jun 2017 14:45:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-23.reflexion.net [208.70.210.23]) (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 E76347BDBC for ; Wed, 28 Jun 2017 14:45:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14921 invoked from network); 28 Jun 2017 14:38:54 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Jun 2017 14:38:54 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 28 Jun 2017 10:38:54 -0400 (EDT) Received: (qmail 25256 invoked from network); 28 Jun 2017 14:38:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 28 Jun 2017 14:38:54 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8936BEC9004; Wed, 28 Jun 2017 07:38:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work From: Mark Millard In-Reply-To: <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> Date: Wed, 28 Jun 2017 07:38:52 -0700 Cc: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 28 Jun 2017 14:45:36 -0000 On 2017-Jun-28, at 3:21 AM, Gerald Pfeifer wrote: > I am testing a patch for gcc5-devel right now that will disable = fixincludes (or rather its fixed files) being packaged. >=20 > Should that work fine for you, I will push this back to gcc5 the = following days. >=20 > That said, the change that triggered this is what I would expect on = CURRENT, not STABLE (and hence hoped we'd have more time for this = change). >=20 > My Internet connectivity right now is only slightly above pigeon = speed, so sorry for any delays. Thanks! Some notes: A primary test is building lang/gcc5-devel under release/11.0.1 and then using it under stable/11 or some draft of release/11.1.0 . It looks like the the lang/gcc5-devel build still creates and uses the headers that go in include-fixed/ but that they are removed from $(STAGEDIR}${TARGLIB} 's tree before installation or packaging. So, if I understand right, lang/gcc5-devel itself still does use the adjusted headers to produce its own materials but when lang/gcc5-devel is used later it does not. Definitely something to be testing since it is a mix overall. Is some form of exp-like run needed that tries to force use of a release/11.0.1 built lang/gcc5-devel (-r444563) to build other things under, say, stable/11 or some draft of release/11.1.0 ? Is this odd combination even possible currently? A normal exp-run on release/11.0.1 without a system version switch being involved also seems appropriate. The same could be said of an exp-run based on a release/11.1.0 draft for both building lang/gcc5-devel and using it to build other things. I had hoped that the Linux =46rom Scratch technique of doing: sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in (or an equivalent) before gcc/Makefile.in is used would allow lang/gcc5-devel to use the same headers in its build that the installed compiler would then use to produce other code --by avoiding generating most of the adjusted files in the first place. But I guess that did not work out. Eventually most of the lang/gcc* 's will need whatever technique is used. Some, such as lang/gcc6-aux, need more done because of binary bootstrap materials being downloaded and used and so the build of lang/gcc6-aux gets the problem and fails before staging happens: the binary-bootstrap materials need to avoid the adjusted headers that they currently contain. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 02:44:40 2017 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 F30ACD8E428 for ; Thu, 29 Jun 2017 02:44:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 A07DA71664 for ; Thu, 29 Jun 2017 02:44:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31302 invoked from network); 29 Jun 2017 02:44:38 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 02:44:38 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 28 Jun 2017 22:44:38 -0400 (EDT) Received: (qmail 6968 invoked from network); 29 Jun 2017 02:44:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 02:44:37 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F0799EC8AEE; Wed, 28 Jun 2017 19:44:36 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: /usr/ports -r444615 (e.g.) & head -r320458 (e.g.): sysutils/u-boot-pine64 build fails for arch/arm/dts/pine64_plus.dtb source handling error (gic in a64.dtsi) Message-Id: <746945FA-AFCD-40FE-AF7E-875B89EC1B4A@dsl-only.net> Date: Wed, 28 Jun 2017 19:44:36 -0700 To: Emmanuel Vadot , freebsd-arm , FreeBSD Toolchain , FreeBSD Ports X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 02:44:40 -0000 Is the below a BSDL vs. GPL DTS issue? In my attempt to build sysutils/u-boot-pine64 I got: OBJCOPY u-boot.srec OBJCOPY u-boot-nodtb.bin start=3D$(aarch64-none-elf-nm u-boot | grep __rel_dyn_start | cut -f 1 = -d ' '); end=3D$(aarch64-none-elf-nm u-boot | grep __rel_dyn_end | cut = -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x4a000000 $start = $end SYM u-boot.sym DTC arch/arm/dts/pine64_plus.dtb Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Expected unit = address gic: interrupt-controller@{ ^ Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Failed to find = root node /. gic: interrupt-controller@{ ^ Failed to parse tree. gmake[3]: *** [scripts/Makefile.lib:299: arch/arm/dts/pine64_plus.dtb] = Error 1 gmake[2]: *** [dts/Makefile:36: arch-dtbs] Error 2 gmake[1]: *** [Makefile:821: dts/dt.dtb] Error 2 gmake[1]: *** Waiting for unfinished jobs.... gmake[1]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05' Looking at the gic part of the source. . . # more = /usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05/ar= ch/arm/dts/a64.dtsi . . . gic: interrupt-controller@{ compatible =3D "arm,gic-400"; interrupt-controller; #interrupt-cells =3D <3>; #address-cells =3D <0>; reg =3D <0x01C81000 0x1000>, <0x01C82000 0x2000>, <0x01C84000 0x2000>, <0x01C86000 0x2000>; interrupts =3D ; }; I'll be trying 3 other u-boot-*'s so I may have more to report later. =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 03:52:21 2017 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 18B8DD90B08 for ; Thu, 29 Jun 2017 03:52:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 C1AF073B1D for ; Thu, 29 Jun 2017 03:52:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10794 invoked from network); 29 Jun 2017 03:52:18 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 03:52:18 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 28 Jun 2017 23:52:18 -0400 (EDT) Received: (qmail 19926 invoked from network); 29 Jun 2017 03:52:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 03:52:18 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D7686EC8A8B; Wed, 28 Jun 2017 20:52:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: /usr/ports -r444615 (e.g.) & head -r320458 (e.g.): sysutils/u-boot-pine64 build fails for arch/arm/dts/pine64_plus.dtb source handling error (gic in a64.dtsi) From: Mark Millard In-Reply-To: <746945FA-AFCD-40FE-AF7E-875B89EC1B4A@dsl-only.net> Date: Wed, 28 Jun 2017 20:52:17 -0700 Cc: freebsd-arm , FreeBSD Toolchain , FreeBSD Ports Content-Transfer-Encoding: quoted-printable Message-Id: <51D64AB6-5E0A-4210-B3B1-CB236F1C9B39@dsl-only.net> References: <746945FA-AFCD-40FE-AF7E-875B89EC1B4A@dsl-only.net> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 03:52:21 -0000 On 2017-Jun-28, at 7:44 PM, Mark Millard wrote: > Is the below a BSDL vs. GPL DTS issue? >=20 > In my attempt to build sysutils/u-boot-pine64 I got: >=20 > OBJCOPY u-boot.srec > OBJCOPY u-boot-nodtb.bin > start=3D$(aarch64-none-elf-nm u-boot | grep __rel_dyn_start | cut -f 1 = -d ' '); end=3D$(aarch64-none-elf-nm u-boot | grep __rel_dyn_end | cut = -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x4a000000 $start = $end > SYM u-boot.sym > DTC arch/arm/dts/pine64_plus.dtb > Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Expected unit = address > gic: interrupt-controller@{ > ^ > Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Failed to find = root node /. > gic: interrupt-controller@{ > ^ > Failed to parse tree. > gmake[3]: *** [scripts/Makefile.lib:299: arch/arm/dts/pine64_plus.dtb] = Error 1 > gmake[2]: *** [dts/Makefile:36: arch-dtbs] Error 2 > gmake[1]: *** [Makefile:821: dts/dt.dtb] Error 2 > gmake[1]: *** Waiting for unfinished jobs.... > gmake[1]: Leaving directory = '/usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05' >=20 >=20 >=20 > Looking at the gic part of the source. . . >=20 > # more = /usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05/ar= ch/arm/dts/a64.dtsi > . . . > gic: interrupt-controller@{ > compatible =3D "arm,gic-400"; > interrupt-controller; > #interrupt-cells =3D <3>; > #address-cells =3D <0>; >=20 > reg =3D <0x01C81000 0x1000>, > <0x01C82000 0x2000>, > <0x01C84000 0x2000>, > <0x01C86000 0x2000>; > interrupts =3D (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>; > }; >=20 >=20 >=20 > I'll be trying 3 other u-boot-*'s so I may have more to > report later. The other 3 that I tried worked fine: Installation of sysutils/u-boot-rpi2 (u-boot-rpi2-2015.04) Installation of sysutils/u-boot-rpi3 (u-boot-rpi3-2017.01) Installation of sysutils/u-boot-sinovoip-bpi-m3 = (u-boot-sinovoip-bpi-m3-2016.05) So this may be unique to a64.dtsi and its lack of hexadecimal digits after the "@" in what I quoted. Still, sysutils/u-boot-pine64 used to build. So it may be a BSDL vs. GPL DTS issue as far as the handling of the notation goes. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 07:48:29 2017 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 30D54D95C93; Thu, 29 Jun 2017 07:48:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 39DBA79D93; Thu, 29 Jun 2017 07:48:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id fa60e2d4; Thu, 29 Jun 2017 09:48:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=QjgwgoXTXTe6gY8byXiDbnv1dNQ=; b=SPG/qNdrasbslzMLNDPU1lBRVfNO t5bEsEbTF0wjmyRjv5BLRGw1nvebl0abDsdaute43aPw0GOtzFXUWSorVe3YPf/v dqAn70iNb0BvT+D1VgvyRtBUdx7op98cVSwK9fcgvGerq5qlKlMyA43eDUfjKCGQ Ti6vOIA6VmejVUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=VNwERX/USSLTVMecPM2D/GG0lZi/C5u29kh+2UeWU+sL/Wu0R3kP3gik AhISmLw0kGS+6nmVWXODBdlovS1bQA2PaaoxMcrJr1Wc/v3xPVd9JNXXg8PPi6V3 XugOvZAx+xhK4D+d1PSF8d8EHyiVEi5Yn0vfRG4xO1cVYW79O1w= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e90134af TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 29 Jun 2017 09:48:18 +0200 (CEST) Date: Thu, 29 Jun 2017 09:48:18 +0200 From: Emmanuel Vadot To: Mark Millard Cc: Emmanuel Vadot , freebsd-arm , FreeBSD Toolchain , FreeBSD Ports Subject: Re: /usr/ports -r444615 (e.g.) & head -r320458 (e.g.): sysutils/u-boot-pine64 build fails for arch/arm/dts/pine64_plus.dtb source handling error (gic in a64.dtsi) Message-Id: <20170629094818.9c851cde402d80b2de30dc55@bidouilliste.com> In-Reply-To: <51D64AB6-5E0A-4210-B3B1-CB236F1C9B39@dsl-only.net> References: <746945FA-AFCD-40FE-AF7E-875B89EC1B4A@dsl-only.net> <51D64AB6-5E0A-4210-B3B1-CB236F1C9B39@dsl-only.net> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 07:48:29 -0000 Hello Mark, On Wed, 28 Jun 2017 20:52:17 -0700 Mark Millard wrote: > On 2017-Jun-28, at 7:44 PM, Mark Millard wrote: > > > Is the below a BSDL vs. GPL DTS issue? > > > > In my attempt to build sysutils/u-boot-pine64 I got: > > > > OBJCOPY u-boot.srec > > OBJCOPY u-boot-nodtb.bin > > start=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_start | cut -f 1 -d ' '); end=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_end | cut -f 1 -d ' '); tools/relocate-rela u-boot-nodtb.bin 0x4a000000 $start $end > > SYM u-boot.sym > > DTC arch/arm/dts/pine64_plus.dtb > > Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Expected unit address > > gic: interrupt-controller@{ > > ^ > > Error at arch/arm/dts/.pine64_plus.dtb.dts.tmp:533:27: Failed to find root node /. > > gic: interrupt-controller@{ > > ^ > > Failed to parse tree. > > gmake[3]: *** [scripts/Makefile.lib:299: arch/arm/dts/pine64_plus.dtb] Error 1 > > gmake[2]: *** [dts/Makefile:36: arch-dtbs] Error 2 > > gmake[1]: *** [Makefile:821: dts/dt.dtb] Error 2 > > gmake[1]: *** Waiting for unfinished jobs.... > > gmake[1]: Leaving directory '/usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05' > > > > > > > > Looking at the gic part of the source. . . > > > > # more /usr/obj/portswork/usr/ports/sysutils/u-boot-pine64/work/u-boot-2016.05/arch/arm/dts/a64.dtsi > > . . . > > gic: interrupt-controller@{ > > compatible = "arm,gic-400"; > > interrupt-controller; > > #interrupt-cells = <3>; > > #address-cells = <0>; > > > > reg = <0x01C81000 0x1000>, > > <0x01C82000 0x2000>, > > <0x01C84000 0x2000>, > > <0x01C86000 0x2000>; > > interrupts = > (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>; > > }; > > Yes the node is wrong but if gpl dtc can handle that maybe we should to, I'll try to find time to fix that. > > > > I'll be trying 3 other u-boot-*'s so I may have more to > > report later. > > The other 3 that I tried worked fine: > > Installation of sysutils/u-boot-rpi2 (u-boot-rpi2-2015.04) > Installation of sysutils/u-boot-rpi3 (u-boot-rpi3-2017.01) > Installation of sysutils/u-boot-sinovoip-bpi-m3 (u-boot-sinovoip-bpi-m3-2016.05) > > So this may be unique to a64.dtsi and its lack of > hexadecimal digits after the "@" in what I quoted. > > Still, sysutils/u-boot-pine64 used to build. So it may > be a BSDL vs. GPL DTS issue as far as the handling of > the notation goes. > > === > Mark Millard > markmi at dsl-only.net I also a patch waiting for comment on the u-boot mailing list that add the possibility to specify which dtc to use, this will be needed for the next u-boot for arm64 board as it uses 'incbin' directive which bsd dtc doesn't support yet (David is looking into it). Anyway, new u-boot should be out around july 10th so I'll update the port right after. Thanks for reporting. -- Emmanuel Vadot From owner-freebsd-toolchain@freebsd.org Thu Jun 29 08:33:49 2017 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 EDDA0D96C6B for ; Thu, 29 Jun 2017 08:33:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 9FEB07B3B9 for ; Thu, 29 Jun 2017 08:33:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28445 invoked from network); 29 Jun 2017 08:33:47 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 08:33:47 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 04:33:47 -0400 (EDT) Received: (qmail 19474 invoked from network); 29 Jun 2017 08:33:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 08:33:47 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8F5B8EC7E56; Thu, 29 Jun 2017 01:33:46 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320458 (e.g.) amd64 -> powerpc cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Message-Id: Date: Thu, 29 Jun 2017 01:33:45 -0700 To: Justin Hibbits , FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 08:33:50 -0000 Beyond static_assert failures and overflow/underflow of long long it also it complains in some cases about: static_assert expression is not an integral constant expression [I will note that attempting a gcc 4.2.1 build did not stop and report such things for its libstdc++. The below is somehow libc++ and/or clang 4 specific.] Context: # uname -apKU FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r320458M amd64 = amd64 1200036 1200036 buildworld for TARGET_ARCH=3Dpowerpc resulted in: --- filesystem/operations.o --- = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 999999999}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 1000000000}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" static_assert(is_representable({min_time_t, 0}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::max()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::min()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^ . . . --- lib__L --- 7 errors generated. *** [filesystem/operations.o] Error code 1 make[5]: stopped in /usr/src/lib/libc++experimental .ERROR_TARGET=3D'filesystem/operations.o' = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib= /libc++experimental/_usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib= _libc++experimental_filesystem_operations.o.meta' .MAKE.LEVEL=3D'5' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o;' .CURDIR=3D'/usr/src/lib/libc++experimental' # more = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta # Meta data file = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta CMD c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o CWD = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental TARGET filesystem/operations.o -- command output -- = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 999999999}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" static_assert(is_representable({max_time_t, 1000000000}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" static_assert(is_representable({min_time_t, 0}), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::max()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" static_assert(!is_representable(file_time_type::min()), ""); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); ^ /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' return __duration_cast, = _ToDuration>()(__fd); ^ /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} ^ /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); ^ 7 errors generated. *** Error code 1 Build configuration: # svnlite info /usr/src/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 320458 Last Changed Rev: 320458 # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ make $* # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host TO_TYPE=3Dpowerpc # KERNCONF=3DGENERICvtsc-NODBG TARGET=3D${TO_TYPE} .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITH_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_ELFTOOLCHAIN_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # # Use WERROR to avoid stopping at the likes of: # error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') = changes value from 128 to -128 [-Werror,-Wconstant-conversion] WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 09:21:43 2017 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 14613D97C5A for ; Thu, 29 Jun 2017 09:21:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 435C07CC37 for ; Thu, 29 Jun 2017 09:21:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23211 invoked from network); 29 Jun 2017 09:21:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 09:21:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 05:21:40 -0400 (EDT) Received: (qmail 22525 invoked from network); 29 Jun 2017 09:21:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 09:21:40 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D8997EC7E56; Thu, 29 Jun 2017 02:21:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: Date: Thu, 29 Jun 2017 02:21:38 -0700 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> References: To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 09:21:43 -0000 [TARGET_ARCH=3Dpowerpc64 fails similarly in its world32 part of its build.] On 2017-Jun-29, at 1:33 AM, Mark Millard wrote: > Beyond static_assert failures and overflow/underflow of long long > it also it complains in some cases about: >=20 > static_assert expression is not an integral constant expression >=20 >=20 > [I will note that attempting a gcc 4.2.1 build did not > stop and report such things for its libstdc++. The below > is somehow libc++ and/or clang 4 specific.] >=20 >=20 > Context: >=20 > # uname -apKU > FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r320458M = amd64 amd64 1200036 1200036 >=20 > buildworld for TARGET_ARCH=3Dpowerpc resulted in: >=20 > --- filesystem/operations.o --- > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 999999999}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 1000000000}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" > static_assert(is_representable({min_time_t, 0}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::max()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::min()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^ > . . . > --- lib__L --- > 7 errors generated. > *** [filesystem/operations.o] Error code 1 >=20 > make[5]: stopped in /usr/src/lib/libc++experimental > .ERROR_TARGET=3D'filesystem/operations.o' > = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib= /libc++experimental/_usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib= _libc++experimental_filesystem_operations.o.meta' > .MAKE.LEVEL=3D'5' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o;' > .CURDIR=3D'/usr/src/lib/libc++experimental' >=20 >=20 > # more = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta > # Meta data file = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta > CMD c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o > CWD = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental > TARGET filesystem/operations.o > -- command output -- > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 999999999}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" > static_assert(is_representable({max_time_t, 1000000000}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" > static_assert(is_representable({min_time_t, 0}), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::max()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" > static_assert(!is_representable(file_time_type::min()), ""); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' > static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); > ^ > /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' > return __duration_cast, = _ToDuration>()(__fd); > ^ > /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' > : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} > ^ > /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' > #define _VSTD std::_LIBCPP_NAMESPACE > ^ > = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' > static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); > ^ > 7 errors generated. > *** Error code 1 >=20 >=20 >=20 > Build configuration: >=20 >=20 > # svnlite info /usr/src/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 320458 > Last Changed Rev: 320458 >=20 >=20 > # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ > make $* >=20 >=20 > # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host > TO_TYPE=3Dpowerpc > # > KERNCONF=3DGENERICvtsc-NODBG > TARGET=3D${TO_TYPE} > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITH_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITH_BINUTILS_BOOTSTRAP=3D > WITH_ELFTOOLCHAIN_BOOTSTRAP=3D > WITH_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLD=3D > # lldb requires missing atomic 8-byte operations for powerpc (non-64) > WITHOUT_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > # > # Use WERROR to avoid stopping at the likes of: > # error: implicit conversion from 'int' to 'int8_t' (aka 'signed = char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] > WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D The world32 part of a TARGET_ARCH=3Dpowerpc64 cross-buildworld also gets the same errors. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 10:04:23 2017 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 28779D98A5B for ; Thu, 29 Jun 2017 10:04:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 DA3357E16E for ; Thu, 29 Jun 2017 10:04:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12079 invoked from network); 29 Jun 2017 10:04:21 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 10:04:21 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 06:04:21 -0400 (EDT) Received: (qmail 1759 invoked from network); 29 Jun 2017 10:04:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 10:04:20 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 37AD1EC8A8B; Thu, 29 Jun 2017 03:04:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> Date: Thu, 29 Jun 2017 03:04:19 -0700 Cc: FreeBSD Toolchain , FreeBSD Current , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 10:04:23 -0000 [The libc++ code in question appears to not be ready for 32-bit contexts with 64 bit times. Disable experimental/filesystem for now? I've submitted llvm bugzilla 33638 for the issue and have added it to llvm's 25780, the FreeBSD META for clang.] On 2017-Jun-29, at 2:21 AM, Mark Millard wrote: > [TARGET_ARCH=3Dpowerpc64 fails similarly in its world32 > part of its build.] >=20 > On 2017-Jun-29, at 1:33 AM, Mark Millard wrote: >=20 >> Beyond static_assert failures and overflow/underflow of long long >> it also it complains in some cases about: >>=20 >> static_assert expression is not an integral constant expression >>=20 >>=20 >> [I will note that attempting a gcc 4.2.1 build did not >> stop and report such things for its libstdc++. The below >> is somehow libc++ and/or clang 4 specific.] >>=20 >>=20 >> Context: >>=20 >> # uname -apKU >> FreeBSD FreeBSDx64OPC 12.0-CURRENT FreeBSD 12.0-CURRENT r320458M = amd64 amd64 1200036 1200036 >>=20 >> buildworld for TARGET_ARCH=3Dpowerpc resulted in: >>=20 >> --- filesystem/operations.o --- >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 999999999}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 1000000000}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" >> static_assert(is_representable({min_time_t, 0}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::max()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::min()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^ >> . . . >> --- lib__L --- >> 7 errors generated. >> *** [filesystem/operations.o] Error code 1 >>=20 >> make[5]: stopped in /usr/src/lib/libc++experimental >> .ERROR_TARGET=3D'filesystem/operations.o' >> = .ERROR_META_FILE=3D'/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib= /libc++experimental/_usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib= _libc++experimental_filesystem_operations.o.meta' >> .MAKE.LEVEL=3D'5' >> MAKEFILE=3D'' >> .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes = silent=3Dyes verbose' >> _ERROR_CMD=3D'c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o;' >> .CURDIR=3D'/usr/src/lib/libc++experimental' >>=20 >>=20 >> # more = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta >> # Meta data file = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental/= _usr_obj_powerpcvtsc_clang_powerpc.powerpc_usr_src_lib_libc++experimental_= filesystem_operations.o.meta >> CMD c++ -target powerpc-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp = -B/usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/tmp/usr/bin -O2 = -pipe -fstack-protector-strong -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses = -Qunused-arguments -fpic -isystem /usr/src/contrib/libc++/include = -nostdinc++ -nostdlib -D_LIBCPP_BUILDING_LIBRARY -DLIBCXXRT -std=3Dc++14 = -Wno-c++11-extensions -c = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp -o = filesystem/operations.o >> CWD = /usr/obj/powerpcvtsc_clang/powerpc.powerpc/usr/src/lib/libc++experimental >> TARGET filesystem/operations.o >> -- command output -- >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:579:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 999999999}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:580:1: = error: static_assert failed "" >> static_assert(is_representable({max_time_t, 1000000000}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:581:1: = error: static_assert failed "" >> static_assert(is_representable({min_time_t, 0}), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:603:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::max()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:604:1: = error: static_assert failed "" >> static_assert(!is_representable(file_time_type::min()), ""); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = 9223372036854775807000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(max_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(max_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:605:47:= note: in call to 'duration(seconds(max_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:15:= error: static_assert expression is not an integral constant expression >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> /usr/src/contrib/libc++/include/chrono:386:59: note: value = -9223372036854775808000000 is outside the range of representable values = of type 'long long' >> static_cast<_Ct>(__fd.count()) * = static_cast<_Ct>(_Period::num))); >> ^ >> /usr/src/contrib/libc++/include/chrono:413:12: note: in call to = '&__duration_cast >, = std::__1::chrono::duration > = >()->operator()(seconds(min_time_t))' >> return __duration_cast, = _ToDuration>()(__fd); >> ^ >> /usr/src/contrib/libc++/include/chrono:560:26: note: in call to = 'duration_cast(seconds(min_time_t))' >> : = __rep_(_VSTD::chrono::duration_cast(__d).count()) {} >> ^ >> /usr/src/contrib/libc++/include/__config:390:15: note: expanded from = macro '_VSTD' >> #define _VSTD std::_LIBCPP_NAMESPACE >> ^ >> = /usr/src/contrib/libc++/src/experimental/filesystem/operations.cpp:606:47:= note: in call to 'duration(seconds(min_time_t), 0)' >> static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); >> ^ >> 7 errors generated. >> *** Error code 1 >>=20 >>=20 >>=20 >> Build configuration: >>=20 >>=20 >> # svnlite info /usr/src/ | grep "Re[plv]" >> Relative URL: ^/head >> Repository Root: svn://svn.freebsd.org/base >> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f >> Revision: 320458 >> Last Changed Rev: 320458 >>=20 >>=20 >> # more = ~/sys_build_scripts.amd64-host/make_powerpcvtsc_nodebug_clang_bootstrap-am= d64-host.sh=20 >> kldload -n filemon && \ >> script = ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_clang_bootstrap-amd6= 4-host-$(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-h= ost" \ >> WITH_META_MODE=3Dyes \ >> MAKEOBJDIRPREFIX=3D"/usr/obj/powerpcvtsc_clang" \ >> make $* >>=20 >>=20 >> # more /root/src.configs/src.conf.powerpc-clang-bootstrap.amd64-host >> TO_TYPE=3Dpowerpc >> # >> KERNCONF=3DGENERICvtsc-NODBG >> TARGET=3D${TO_TYPE} >> .if ${.MAKE.LEVEL} =3D=3D 0 >> TARGET_ARCH=3D${TO_TYPE} >> .export TARGET_ARCH >> .endif >> # >> WITH_CROSS_COMPILER=3D >> WITHOUT_SYSTEM_COMPILER=3D >> # >> WITH_LIBCPLUSPLUS=3D >> WITH_BINUTILS_BOOTSTRAP=3D >> WITH_ELFTOOLCHAIN_BOOTSTRAP=3D >> WITH_CLANG_BOOTSTRAP=3D >> WITH_CLANG=3D >> WITH_CLANG_IS_CC=3D >> WITH_CLANG_FULL=3D >> WITH_CLANG_EXTRAS=3D >> WITH_LLD=3D >> # lldb requires missing atomic 8-byte operations for powerpc (non-64) >> WITHOUT_LLDB=3D >> # >> WITH_BOOT=3D >> WITHOUT_LIB32=3D >> # >> WITHOUT_GCC_BOOTSTRAP=3D >> WITHOUT_GCC=3D >> WITHOUT_GCC_IS_CC=3D >> WITHOUT_GNUCXX=3D >> # >> NO_WERROR=3D >> # >> # Use WERROR to avoid stopping at the likes of: >> # error: implicit conversion from 'int' to 'int8_t' (aka 'signed = char') changes value from 128 to -128 [-Werror,-Wconstant-conversion] >> WERROR=3D >> MALLOC_PRODUCTION=3D >> # >> WITH_REPRODUCIBLE_BUILD=3D >> WITH_DEBUG_FILES=3D >=20 >=20 > The world32 part of a TARGET_ARCH=3Dpowerpc64 cross-buildworld > also gets the same errors. Turns out the libc++ code in question looks like: _LIBCPP_CONSTEXPR_AFTER_CXX11 bool is_representable(TimeSpec const& tm) { if (tm.tv_sec >=3D 0) { return (tm.tv_sec < max_seconds) || (tm.tv_sec =3D=3D max_seconds && tm.tv_nsec <=3D max_nsec); } else if (tm.tv_sec =3D=3D (min_seconds - 1)) { return tm.tv_nsec >=3D min_nsec_timespec; } else { return (tm.tv_sec >=3D min_seconds); } } #ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR #if defined(__LP64__) . . . #else static_assert(is_representable({max_time_t, 999999999}), ""); static_assert(is_representable({max_time_t, 1000000000}), ""); static_assert(is_representable({min_time_t, 0}), ""); #endif #endif =20 _LIBCPP_CONSTEXPR_AFTER_CXX11 bool is_representable(file_time_type const& tm) { auto secs =3D duration_cast(tm.time_since_epoch()); auto nsecs =3D duration_cast(tm.time_since_epoch() - = secs); if (nsecs.count() < 0) { secs =3D secs + seconds(1); nsecs =3D nsecs + seconds(1); } using TLim =3D numeric_limits; if (secs.count() >=3D 0) return secs.count() <=3D TLim::max(); return secs.count() >=3D TLim::min(); } #ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR #if defined(__LP64__) . . . #else static_assert(!is_representable(file_time_type::max()), ""); static_assert(!is_representable(file_time_type::min()), ""); static_assert(is_representable(file_time_type(seconds(max_time_t))), = ""); static_assert(is_representable(file_time_type(seconds(min_time_t))), = ""); #endif #endif _LIBCPP_CONSTEXPR_AFTER_CXX11 file_time_type convert_timespec(TimeSpec const& tm) { auto adj_msec =3D = duration_cast(nanoseconds(tm.tv_nsec)); if (tm.tv_sec >=3D 0) { auto Dur =3D seconds(tm.tv_sec) + microseconds(adj_msec); return file_time_type(Dur); } else if = (duration_cast(nanoseconds(tm.tv_nsec)).count() =3D=3D 0) = { return file_time_type(seconds(tm.tv_sec)); } else { // tm.tv_sec < 0 auto adj_subsec =3D duration_cast(seconds(1) - = nanoseconds(tm.tv_nsec)); auto Dur =3D seconds(tm.tv_sec + 1) - adj_subsec; return file_time_type(Dur); } } #ifndef _LIBCPP_HAS_NO_CXX14_CONSTEXPR #if defined(__LP64__) . . . #else // FIXME add tests for 32 bit builds #endif #endif That "FIXME" likely gives a clue as to the status of of the handling for ILP32 contexts. There seems to be the expectation that IPL32 will not have 64-bit time_t as well. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 10:10:59 2017 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 16C8DD98D60; Thu, 29 Jun 2017 10:10:59 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (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 E2A0C7E4FB; Thu, 29 Jun 2017 10:10:58 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (localhost [127.0.0.1]) by ainaz.pair.com (Postfix) with ESMTP id A7BCB3F4D9; Thu, 29 Jun 2017 06:10:56 -0400 (EDT) Received: from [192.168.1.102] (unknown [202.188.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id D30993F4D5; Thu, 29 Jun 2017 06:10:37 -0400 (EDT) Date: Thu, 29 Jun 2017 18:10:16 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work To: Mark Millard CC: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni From: Gerald Pfeifer Message-ID: X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 10:10:59 -0000 Am 28=2E Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard : >A primary test is building lang/gcc5-devel under release/11=2E0=2E1 >and then using it under stable/11 or some draft of release/11=2E1=2E0 =2E Thank you, Mark=2E Let me know how it went=2E In the meantime I'll prepare= the change for gcc5 itself=2E >It looks like the the lang/gcc5-devel build still creates and >uses the headers that go in include-fixed/ but that they are >removed from $(STAGEDIR}${TARGLIB} 's tree before installation >or packaging=2E > >So, if I understand right, lang/gcc5-devel itself still does use >the adjusted headers to produce its own materials but when >lang/gcc5-devel is used later it does not=2E Definitely >something to be testing since it is a mix overall=2E I am not worried about that since that should not cause any binary incompa= tibilities (ABI)=2E The problem we encountered was about source code and AP= I in a wide sense of that term=2E >Is some form of exp-like run needed that tries to force use >of a release/11=2E0=2E1 built lang/gcc5-devel (-r444563) to build >other things under, say, stable/11 or some draft of >release/11=2E1=2E0 ? Is this odd combination even possible >currently? I am not aware of it, and while originally I was thinking to request an -e= xp run (after the GCC version update which is dragging due to broken ports)= , time is not on our side and the change should be low risk=2E > [altermative approach] But I guess that did not work out=2E Not with my current level of connectivity and my notebook a dead brick on = top of that=2E And my preference is to still build, but stow away (unless e= xplicitly requested to keep)=2E >Eventually most of the lang/gcc* 's will need whatever >technique is used=2E Yes, agreed=2E Version 5 is most important since it's the default; then 6;= 4=2Ex is for retro computing fans ;-), so 7 will then be next=2E Gerald From owner-freebsd-toolchain@freebsd.org Thu Jun 29 10:47:27 2017 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 83CD4D998BF; Thu, 29 Jun 2017 10:47:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (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 4AF197F66D; Thu, 29 Jun 2017 10:47:27 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.avinity.tv (unknown [77.95.97.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 859203610B; Thu, 29 Jun 2017 12:47:24 +0200 (CEST) From: Dimitry Andric Message-Id: <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Date: Thu, 29 Jun 2017 12:47:10 +0200 In-Reply-To: Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current To: Mark Millard References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 10:47:27 -0000 --Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 29 Jun 2017, at 12:04, Mark Millard wrote: > > [The libc++ code in question appears to not be ready for > 32-bit contexts with 64 bit times. Disable > experimental/filesystem for now? I've submitted > llvm bugzilla 33638 for the issue and have > added it to llvm's 25780, the FreeBSD META for > clang.] Yes, this also broke earlier on arm and mips, which is why there is the following in lib/Makefile: .if ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips" _libcplusplus+= libc++experimental .endif I haven't yet found the time to address this issue. Upstream should already be aware of it, though. One nasty problem with this is that it is not possible to figure out at compile time what the size of time_t is. You always need some sort of configure-time test, and an external define. -Dimitry --Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllU2rsACgkQsF6jCi4glqNamACfRXH3Q0QNcEPOzK2H7KCmwgLz oAoAnRy1xkn/1oXK7qgTm5Lx8a6r7Tqt =+cuF -----END PGP SIGNATURE----- --Apple-Mail=_A202DD99-D88D-4954-9D60-71CF9D49724A-- From owner-freebsd-toolchain@freebsd.org Thu Jun 29 10:56:02 2017 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 913B2D99C36 for ; Thu, 29 Jun 2017 10:56:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 3EFC67FBE4 for ; Thu, 29 Jun 2017 10:56:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5265 invoked from network); 29 Jun 2017 10:56:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 10:56:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 06:56:00 -0400 (EDT) Received: (qmail 18968 invoked from network); 29 Jun 2017 10:56:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 10:56:00 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A1C33EC7B46; Thu, 29 Jun 2017 03:55:59 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work From: Mark Millard In-Reply-To: Date: Thu, 29 Jun 2017 03:55:59 -0700 Cc: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 10:56:02 -0000 On 2017-Jun-29, at 3:10 AM, Gerald Pfeifer = wrote: > Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard : >> A primary test is building lang/gcc5-devel under release/11.0.1 >> and then using it under stable/11 or some draft of release/11.1.0 . >=20 > Thank you, Mark. Let me know how it went. In the meantime I'll prepare = the change for gcc5 itself. I'm not currently set up to run more than head on any of amd64, powerpc64, powerpc, aarch64, or armv6/7 (which are all I target). And I'm in the middle of attempting a fairly large jump to head -r320458 on those. (powerpc 32-bit and 64-bit just failed for libc++ time-usage compiling now that 32-bit has 64-bit time_t, including in world32/lib32 contexts for powerpc64.) It will likely be a while before I manage to have a 11.x context (without losing my head contexts), much less examples from all "my" 5 TARGET_ARCH's. (Given past wchar_t type handling problems (e.g.) for gcc targeting powerpc family members I think it should be checked.) I'll have to find and set up disks: I do not even have such handy/ready at the moment. [I got into this area by being asked questions, not by my direct use of release/11.0.1 , stable/11 , or a draft of release/11.1.0 .] I'll let you know when I have some test results but others may get some before I do. > . . . >> Eventually most of the lang/gcc* 's will need whatever >> technique is used. >=20 > Yes, agreed. Version 5 is most important since it's the default; then = 6; 4.x is for retro computing fans ;-), so 7 will then be next. [In my normal/head environment I'm switching to lang/gcc7-devel for gcc (from lang/gcc6 ) but I'm odd that way.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 12:54:13 2017 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 1DE45D9CEC4; Thu, 29 Jun 2017 12:54:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 A356C8388F; Thu, 29 Jun 2017 12:54:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5TCs7SF007230 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jun 2017 15:54:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5TCs7SF007230 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5TCs7Eg007229; Thu, 29 Jun 2017 15:54:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Jun 2017 15:54:07 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD Current Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Message-ID: <20170629125407.GM1935@kib.kiev.ua> References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> User-Agent: Mutt/1.8.3 (2017-05-23) 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.23 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, 29 Jun 2017 12:54:13 -0000 On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: > One nasty problem with this is that it is not possible to figure out at > compile time what the size of time_t is. You always need some sort of > configure-time test, and an external define. It is arguably possible, with constexpr. From owner-freebsd-toolchain@freebsd.org Thu Jun 29 17:16:34 2017 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 9A137DA1778 for ; Thu, 29 Jun 2017 17:16:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 49E366726B for ; Thu, 29 Jun 2017 17:16:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31207 invoked from network); 29 Jun 2017 17:16:31 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 17:16:31 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 13:16:31 -0400 (EDT) Received: (qmail 5689 invoked from network); 29 Jun 2017 17:16:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 17:16:31 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C3333EC7E56; Thu, 29 Jun 2017 10:16:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: <20170629125407.GM1935@kib.kiev.ua> Date: Thu, 29 Jun 2017 10:16:30 -0700 Cc: Dimitry Andric , Justin Hibbits , FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <22F5CFA1-E6A9-4C41-BD43-967105B44C49@dsl-only.net> References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> <20170629125407.GM1935@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 17:16:34 -0000 On 2017-Jun-29, at 5:54 AM, Konstantin Belousov = wrote: >=20 > On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: >> One nasty problem with this is that it is not possible to figure out = at >> compile time what the size of time_t is. You always need some sort = of >> configure-time test, and an external define. >=20 > It is arguably possible, with constexpr. I took Dimitry's wording as probably referring to testing the size in the C/C++ preprocessor like the original code tests for __LP64__ being defined vs. not to control what it does: extending that to involve more preprocessor tests to pick from more code blocks. (But it is a guess given his wording.) I also took him to be excluding C++17's if-constexpr (or that the limitations in where how it can be used would prevent his intent) --and excluding the types of meta-programming/Substitution-Failure-Is-Not-An-Error usage that if-constexpr can simplify: too much rework of parts of libc++. Net result: extending the Makefile's "if" that he referenced with a powerpc-family test removes something in more contexts than have the problem. I think that he was wishing for a simple way to avoid that loss but still prevent the problem cases. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 17:33:12 2017 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 488C8DA1C42 for ; Thu, 29 Jun 2017 17:33:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 E3C9267DD0 for ; Thu, 29 Jun 2017 17:33:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2826 invoked from network); 29 Jun 2017 17:34:40 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 17:34:40 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 13:33:10 -0400 (EDT) Received: (qmail 3134 invoked from network); 29 Jun 2017 17:33:10 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 17:33:10 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6D0D0EC7E56; Thu, 29 Jun 2017 10:33:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) From: Mark Millard In-Reply-To: <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> Date: Thu, 29 Jun 2017 10:33:09 -0700 Cc: Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> To: Dimitry Andric X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 17:33:12 -0000 [Good news from the llvm side of things. . .] On 2017-Jun-29, at 3:47 AM, Dimitry Andric wrote: > On 29 Jun 2017, at 12:04, Mark Millard wrote: >>=20 >> [The libc++ code in question appears to not be ready for >> 32-bit contexts with 64 bit times. Disable >> experimental/filesystem for now? I've submitted >> llvm bugzilla 33638 for the issue and have >> added it to llvm's 25780, the FreeBSD META for >> clang.] >=20 > Yes, this also broke earlier on arm and mips, which is why there is = the > following in lib/Makefile: >=20 > .if ${MACHINE_CPUARCH} !=3D "arm" && ${MACHINE_CPUARCH} !=3D "mips" > _libcplusplus+=3D libc++experimental > .endif >=20 > I haven't yet found the time to address this issue. Upstream should > already be aware of it, though. >=20 > One nasty problem with this is that it is not possible to figure out = at > compile time what the size of time_t is. You always need some sort of > configure-time test, and an external define. I got a notice of a pending patch for the issue: Begin forwarded message: From: bugzilla-daemon at llvm.org Subject: [Bug 33638] FreeBSD head -r320347 moved TARGET_ARCH=3Dpowerpc = to 64-bit time_t but now experimental/filesystem/operations.cpp fails = static_asserts and such Date: June 29, 2017 at 10:23:56 AM PDT . . . Comment # 2 on bug 33638 from Eric Fiselier I have a patch for this waiting in the wings. I should be able to get to = it next week =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Jun 29 21:46:53 2017 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 061E7DA622B; Thu, 29 Jun 2017 21:46:53 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (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 B273A74E59; Thu, 29 Jun 2017 21:46:52 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::287b:b74d:6dec:6d86] (unknown [IPv6:2001:470:7a58:0:287b:b74d:6dec:6d86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 28C1E3615C; Thu, 29 Jun 2017 23:46:50 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build) Date: Thu, 29 Jun 2017 23:46:25 +0200 In-Reply-To: <22F5CFA1-E6A9-4C41-BD43-967105B44C49@dsl-only.net> Cc: Konstantin Belousov , Justin Hibbits , FreeBSD Toolchain , FreeBSD Current To: Mark Millard References: <5B12D9A6-C9A2-4B0D-B32D-D04D7DB1E3BC@dsl-only.net> <55A1694D-BC40-49AE-BEF7-CEE502126E96@FreeBSD.org> <20170629125407.GM1935@kib.kiev.ua> <22F5CFA1-E6A9-4C41-BD43-967105B44C49@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 21:46:53 -0000 --Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Jun 2017, at 19:16, Mark Millard wrote: >=20 > On 2017-Jun-29, at 5:54 AM, Konstantin Belousov wrote: >>=20 >> On Thu, Jun 29, 2017 at 12:47:10PM +0200, Dimitry Andric wrote: >>> One nasty problem with this is that it is not possible to figure out = at >>> compile time what the size of time_t is. You always need some sort = of >>> configure-time test, and an external define. >>=20 >> It is arguably possible, with constexpr. >=20 > I took Dimitry's wording as probably referring to > testing the size in the C/C++ preprocessor like > the original code tests for __LP64__ being defined > vs. not to control what it does: extending that to > involve more preprocessor tests to pick from more > code blocks. (But it is a guess given his wording.) Yeah, what I meant is that the code does something like: #if __LP64__ static_assert(whatever, "foo"); #else static_assert(otherthing, "bar"); #endif where __LP64__ was erroneously thought to determine whether time_t was 64-bit. You cannot replace this with something like the following C++11 construct, though: constexpr bool time_t_64bit =3D sizeof(time_t) =3D=3D 8; if (time_t_64bit) static_assert(true, "time_t is OK"); else static_assert(false, "time_t is bad"); because both static assertions will be evaluated at compile time, and one of them will fail. In any case, Eric Fiselier already had some sort of patch lined up, but I slacked off on trying it out. Sorry about that. :) -Dimitry --Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllVdUkACgkQsF6jCi4glqN3wACfVKTqwhL8YMitgny3Am39EozG vcIAnR4c7W/vYn89hZEtrWmXhek3Dis/ =CeAt -----END PGP SIGNATURE----- --Apple-Mail=_8A2FDD54-3A69-4E51-A000-4009D22E1C4F-- From owner-freebsd-toolchain@freebsd.org Thu Jun 29 22:33:35 2017 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 14079DA712F for ; Thu, 29 Jun 2017 22:33:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 C90677661F for ; Thu, 29 Jun 2017 22:33:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19155 invoked from network); 29 Jun 2017 22:33:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Jun 2017 22:33:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 18:33:27 -0400 (EDT) Received: (qmail 10482 invoked from network); 29 Jun 2017 22:33:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Jun 2017 22:33:27 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6931EEC8029; Thu, 29 Jun 2017 15:33:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) Message-Id: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> Date: Thu, 29 Jun 2017 15:33:25 -0700 To: Bryan Drewery , Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 29 Jun 2017 22:33:35 -0000 [This is a clang targetting powerpc64 context from my experimentation efforts, not the normal gcc 4.2.1 context for powerpc64.] I break out the PATH into lines below to make it easier to scan. See the later "sh: head: not found" line and the even later ls of the directory with the x86-64 program directory in use: no "head" is present to find. --- install32 --- cd /usr/src/lib; MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc = MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerp= c64/usr/src/world32 = PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/= tmp/legacy/usr/sbin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/usr/bin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/bin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/sbin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/bin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/usr/sbin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/usr/bin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/bin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/sbin = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/bin :/tmp/install.7ljKosWa = SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/lib32 LIBDIR=3D/usr/lib32 SHLIBDIR=3D/usr/lib32 DTRACE=3D"dtrace" = make LD=3D"/usr/local/powerpc64-freebsd/bin/ld -m elf32ppc_fbsd" = OBJCOPY=3D"/usr/local/powerpc64-freebsd/bin/objcopy" = NM=3D"/usr/local/powerpc64-freebsd/bin/nm" -DCOMPAT_32BIT CC=3D"cc = -target powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT = -mcpu=3Dpowerpc -m32 = -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/lib32 -B/usr/local/powerpc64-freebsd/bin/ = -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32" CXX=3D"c++ -target powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT = -mcpu=3Dpowerpc -m32 = -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/lib32 -B/usr/local/powerpc64-freebsd/bin/ = -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32" CPP=3D"cpp -target powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT = -mcpu=3Dpowerpc -m32 = -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/lib32 -B/usr/local/powerpc64-freebsd/bin/ = -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32" -DNO_CPU_CFLAGS MK_CTF=3Dno -DNO_LINT MK_TESTS=3Dno = MK_MAN=3Dno MK_HTML=3Dno MK_TOOLCHAIN=3Dno -DLIBRARIES_ONLY install sh: head: not found make[4]: "/usr/src/share/mk/bsd.linker.mk" line 47: Unable to determine = linker type from XLD=3D/usr/local/powerpc64-freebsd/bin/ld *** [install32] Error code 1 # ls -lT /tmp/install.7ljKosWa/ total 6151 -r-xr-xr-x 1 root wheel 12592 Jun 29 14:02:46 2017 [ -r-xr-xr-x 1 root wheel 207320 Jun 29 14:02:46 2017 awk -r-xr-xr-x 1 root wheel 8456 Jun 29 14:02:46 2017 cap_mkdb -r-xr-xr-x 1 root wheel 13272 Jun 29 14:02:46 2017 cat . . . -r-xr-xr-x 1 root wheel 57632 Jun 29 14:02:46 2017 find -r-xr-xr-x 1 root wheel 99064 Jun 29 14:02:46 2017 grep -r-xr-xr-x 1 root wheel 13360 Jun 29 14:02:46 2017 id . . . So there is no "head" to find. Below uses "find" instead to confirm the x86-64 ELF status: # file /tmp/install.7ljKosWa/find /tmp/install.7ljKosWa/find: ELF 64-bit LSB executable, x86-64, version 1 = (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for = FreeBSD 12.0 (1200036), FreeBSD-style, stripped =46rom /usr/src/share/mk/bsd.linker.mk : .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) _ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || echo = none .if ${_ld_version} =3D=3D "none" .error Unable to determine linker type from ${ld}=3D${${ld}} .endif Trying the failing line interactively (no PATH like above though): # /usr/local/powerpc64-freebsd/bin/ld --version 2>/dev/null | head -n 1 = || echo none GNU ld (GNU Binutils) 2.28 So /tmp/install.7ljKosWa/ just needed a copy of head in addition to what it already had. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jun 30 00:59:05 2017 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 B4C35DA947C; Fri, 30 Jun 2017 00:59:05 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (ainaz.pair.com [209.68.2.66]) (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 827407A131; Fri, 30 Jun 2017 00:59:05 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from ainaz.pair.com (localhost [127.0.0.1]) by ainaz.pair.com (Postfix) with ESMTP id 47A943F4D9; Thu, 29 Jun 2017 20:58:58 -0400 (EDT) Received: from [192.168.1.108] (unknown [202.188.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ainaz.pair.com (Postfix) with ESMTPSA id 65C463F4D5; Thu, 29 Jun 2017 20:58:41 -0400 (EDT) Date: Fri, 30 Jun 2017 08:58:21 +0800 User-Agent: K-9 Mail for Android In-Reply-To: References: <6FD738D6-F163-4BC5-8E6E-A9B9F35595CD@dsl-only.net> <82A991B0-FD8B-457F-8483-D61AE5E6D6F6@pfeifer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work To: Mark Millard CC: papowell@astart.com, FreeBSD-STABLE Mailing List , FreeBSD Toolchain , FreeBSD Ports , Pedro Giffuni From: Gerald Pfeifer Message-ID: X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Jun 2017 00:59:05 -0000 Am 29=2E Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard : >I'm not currently set up to run more than head on >any of amd64, powerpc64, powerpc, aarch64, or armv6/7 >(which are all I target)=2E And I'm in the middle of >attempting a fairly large jump to head -r320458 on >those=2E Oh, then I had misunderstood your previous mail=2E No worries, I'll gently= proceed then=2E I expect to update gcc5 in the next 24 hours=2E >[In my normal/head environment I'm switching to lang/gcc7-devel >for gcc (from lang/gcc6 ) but I'm odd that way=2E] The compiler should be fine, it's a number of ports that are not (even blo= cking the move from GCC 5 to 6 as default)=2E Gerald From owner-freebsd-toolchain@freebsd.org Fri Jun 30 01:21:53 2017 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 9CDA1DA9E8A for ; Fri, 30 Jun 2017 01:21:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 5DA557ABEC for ; Fri, 30 Jun 2017 01:21:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9512 invoked from network); 30 Jun 2017 01:26:05 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Jun 2017 01:26:05 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Thu, 29 Jun 2017 21:21:51 -0400 (EDT) Received: (qmail 24331 invoked from network); 30 Jun 2017 01:21:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jun 2017 01:21:51 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8D0D8EC8AD1; Thu, 29 Jun 2017 18:21:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320458 (e.g.) amd64 -> powerpc64 cross build's install32 during installworld: /usr/src/share/mk/bsd.linker.mk tried to use "head" when PATH provided no access (head is missing) From: Mark Millard In-Reply-To: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> Date: Thu, 29 Jun 2017 18:21:50 -0700 Cc: Bryan Drewery , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <0E42D991-D350-4DC1-A683-CEA506167520@dsl-only.net> To: Ed Maste X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Jun 2017 01:21:53 -0000 [I found where the tools are listed that are copied, the list that is missing head.] On 2017-Jun-29, at 3:33 PM, Mark Millard wrote: > [This is a clang targetting powerpc64 context from my > experimentation efforts, not the normal gcc 4.2.1 context > for powerpc64.] >=20 > I break out the PATH into lines below to make it easier to scan. > See the later "sh: head: not found" line and the even later ls > of the directory with the x86-64 program directory in use: no > "head" is present to find. >=20 > --- install32 --- > cd /usr/src/lib; MACHINE=3Dpowerpc MACHINE_ARCH=3Dpowerpc = MAKEOBJDIRPREFIX=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerp= c64/usr/src/world32 > = PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/= tmp/legacy/usr/sbin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/usr/bin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/bin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/sbin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/bin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/usr/sbin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/usr/bin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/le= gacy/bin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/sbin > = :/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/tmp/us= r/bin > :/tmp/install.7ljKosWa > = SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/lib32 LIBDIR=3D/usr/lib32 SHLIBDIR=3D/usr/lib32 DTRACE=3D"dtrace" = make LD=3D"/usr/local/powerpc64-freebsd/bin/ld -m elf32ppc_fbsd" = OBJCOPY=3D"/usr/local/powerpc64-freebsd/bin/objcopy" = NM=3D"/usr/local/powerpc64-freebsd/bin/nm" -DCOMPAT_32BIT CC=3D"cc = -target powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT = -mcpu=3Dpowerpc -m32 = -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/lib32 -B/usr/local/powerpc64-freebsd/bin/ = -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32" CXX=3D"c++ -target powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT = -mcpu=3Dpowerpc -m32 -L/ > = usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32/us= r/lib32 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/lib32 -B/usr/local/powerpc64-freebsd/bin/ = -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32" CPP=3D"cpp -target powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/tmp -B/usr/local/powerpc64-freebsd/bin/ -DCOMPAT_32BIT = -mcpu=3Dpowerpc -m32 = -L/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/lib32 -B/usr/local/powerpc64-freebsd/bin/ = -B/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/lib32= /usr/lib32" -DNO_CPU_CFLAGS MK_CTF=3Dno -DNO_LINT MK_TESTS=3Dno = MK_MAN=3Dno MK_HTML=3Dno MK_TOOLCHAIN=3Dno -DLIBRARIES_ONLY install > sh: head: not found > make[4]: "/usr/src/share/mk/bsd.linker.mk" line 47: Unable to = determine linker type from XLD=3D/usr/local/powerpc64-freebsd/bin/ld > *** [install32] Error code 1 >=20 > # ls -lT /tmp/install.7ljKosWa/ > total 6151 > -r-xr-xr-x 1 root wheel 12592 Jun 29 14:02:46 2017 [ > -r-xr-xr-x 1 root wheel 207320 Jun 29 14:02:46 2017 awk > -r-xr-xr-x 1 root wheel 8456 Jun 29 14:02:46 2017 cap_mkdb > -r-xr-xr-x 1 root wheel 13272 Jun 29 14:02:46 2017 cat > . . . > -r-xr-xr-x 1 root wheel 57632 Jun 29 14:02:46 2017 find > -r-xr-xr-x 1 root wheel 99064 Jun 29 14:02:46 2017 grep > -r-xr-xr-x 1 root wheel 13360 Jun 29 14:02:46 2017 id > . . . >=20 > So there is no "head" to find. Below uses "find" instead > to confirm the x86-64 ELF status: >=20 > # file /tmp/install.7ljKosWa/find > /tmp/install.7ljKosWa/find: ELF 64-bit LSB executable, x86-64, version = 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for = FreeBSD 12.0 (1200036), FreeBSD-style, stripped >=20 >=20 >=20 > =46rom /usr/src/share/mk/bsd.linker.mk : >=20 > .if ${ld} =3D=3D "LD" || (${ld} =3D=3D "XLD" && ${XLD} !=3D ${LD}) > .if !defined(${X_}LINKER_TYPE) || !defined(${X_}LINKER_VERSION) > _ld_version!=3D ${${ld}} --version 2>/dev/null | head -n 1 || echo = none > .if ${_ld_version} =3D=3D "none" > .error Unable to determine linker type from ${ld}=3D${${ld}} > .endif >=20 >=20 > Trying the failing line interactively (no PATH > like above though): >=20 > # /usr/local/powerpc64-freebsd/bin/ld --version 2>/dev/null | head -n = 1 || echo none > GNU ld (GNU Binutils) 2.28 >=20 > So /tmp/install.7ljKosWa/ just needed a copy of head > in addition to what it already had. In /usr/src/Makefile.inc1 : ITOOLS=3D [ awk cap_mkdb cat chflags chmod chown cmp cp \ date echo egrep find grep id install ${_install-info} \ ln make mkdir mtree mv pwd_mkdb \ rm sed services_mkdb sh strip sysctl test true uname wc = ${_zoneinfo} \ ${LOCAL_ITOOLS} does not list "head" as a tool. But I can externally add it via LOCAL_ITOOLS use. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Jun 30 20:35:46 2017 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 7A79DD9A2B8 for ; Fri, 30 Jun 2017 20:35:46 +0000 (UTC) (envelope-from sid@bsdmail.com) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail.gmx.com", Issuer "thawte SSL CA - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AFA87C335 for ; Fri, 30 Jun 2017 20:35:46 +0000 (UTC) (envelope-from sid@bsdmail.com) Received: from [108.70.50.7] by 3capp-mailcom-lxa05.server.lan (via HTTP); Fri, 30 Jun 2017 22:35:43 +0200 MIME-Version: 1.0 Message-ID: From: Sid To: freebsd-toolchain@freebsd.org Subject: suggestion for toolchain to have its own directories Content-Type: text/plain; charset=UTF-8 Date: Fri, 30 Jun 2017 22:35:43 +0200 Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K1:DeOkNF+wFqVxjU/1u5O2ulp8yQyO9y42Je5qQ5JBEH7 hBDRsJSewXOZZuhWh7MBCgIUkY9O9UQPhRqsFg++hhbXw2w6pg dPY1db+9cIrXkU+M6xvAl+8oYRC68qSuJORL+65eMJWUDnHmPj GKK/F173/IC4IxuNC7srYD+rBb8yVLOXLRYcDRwehv2dYuUAqy plBS0iJ4wVB6Mqj7hWxusNQ67s7/tXepizpIbEsj78i3H5TI/j 5getUiIsp4RAkKQjphjlKmclqFmWaZdxlpOgkYt5yV/VSpm+Sv Fxr92rLjjdjK5JRiwhQN3R6DUph X-UI-Out-Filterresults: notjunk:1;V01:K0:eZcpPsfbkjU=:szXBqw5clmSdN5/TucHDCZ ypq+TjEzgzhMRoTe2kE7WlOlqiPQroMFjDiBBVybgx09NVf7IGZJnW8Ti2lNRBkg7QchF23Ev m/PnU+lpkWBz/kc3XRyVKzXCAiz1WEUWNTfLTTM1fkB0PmLwXBSPcNd0a4QEWip5tKpBtCE9s RXSoi6UVaZZaVtDRsaeIZ5w5u4s7jpegAH2VF4bLFPX6pxz4teJzGbhhNqjXQ2aDKLVciMIJK Et82XmiI7yIAr3aRPJjrLZJDs/L8hkwTTBYT/OVyBfBGyIHH4ZIp0qCCR7j0HiS5MhC8pDUuj vu1jczgBLiHLwLVUQEJ95savkcZvVZVnXhDFzt2y8v2oZXE3vcWPaFF6hlkbTuJ9qZ8Ghe+CO WaapAWsKw3PYqe61faJodBp66FA2/jvkfIqyKZMLn1OqAoN4FxPdrT7/h/zXaiq5o6OGkTKLJ rb8+nwTuck3uGlLfKO0D7fklmJ9vbPJWm8hDoM2LepohuJjpbROPfgeqsOvIr8/TWvtwKreTh L5Na8h+b5UXLY/wrCM/c4w= X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Jun 2017 20:35:46 -0000 Hello, Wouldn't it make sense for toolchains, compilers and their libraries to have their own dedicated top level directories like something under /usr/toolchain/ and /usr/local/toolchain/ in the latest FreeBSD versions? It would be easier for maintenance, and organization of compilers and toolchain components. From owner-freebsd-toolchain@freebsd.org Fri Jun 30 21:13:32 2017 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 CBB22D9A9AD for ; Fri, 30 Jun 2017 21:13:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-15.reflexion.net [208.70.210.15]) (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 79C9E7D282 for ; Fri, 30 Jun 2017 21:13:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31340 invoked from network); 30 Jun 2017 21:17:45 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Jun 2017 21:17:45 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 30 Jun 2017 17:13:29 -0400 (EDT) Received: (qmail 31293 invoked from network); 30 Jun 2017 21:13:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Jun 2017 21:13:29 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 143AEEC8AD1; Fri, 30 Jun 2017 14:13:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: suggestion for toolchain to have its own directories From: Mark Millard X-Priority: 3 In-Reply-To: Date: Fri, 30 Jun 2017 14:13:28 -0700 Cc: freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sid X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 30 Jun 2017 21:13:32 -0000 On 2017-Jun-30, at 1:35 PM, Sid wrote: > Wouldn't it make sense for toolchains, compilers and their libraries = to have their own dedicated top level directories like something under = /usr/toolchain/ and /usr/local/toolchain/ in the latest FreeBSD = versions? It would be easier for maintenance, and organization of = compilers and toolchain components. It is not clear if you are familiar with the following for descriptions of how things are organized: https://www.freebsd.org/doc/handbook/dirstructure.html and covering more: = https://www.freebsd.org/cgi/man.cgi?query=3Dhier&sektion=3D7&manpath=3Dfre= ebsd-release-ports Linux has its structures as well, see: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard and covering more: http://man7.org/linux/man-pages/man7/hier.7.html There is some commonality. Both contexts are based on earlier Unix and Unix-like hierarchies. And the commonality helps with making ports and such easier to support as an example. The types of systems are not completely independent. Lots of tools and such are based on knowing current placements and general properties of the hierarchies. Reorganizations are a big deal and do not happen often. It is also messy for ports to organize things differently than upstream does. So things like lang/gcc7-devel are unlikely to go to the effort of being significantly different when the commonality covers most of the placements already (at least for default configurations). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Jul 1 10:01:29 2017 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 07470DA8C35 for ; Sat, 1 Jul 2017 10:01:29 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (xvm-110-62.dc2.ghst.net [46.226.110.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "theravensnest.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FB468089D for ; Sat, 1 Jul 2017 10:01:28 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from user-109-59.vpn.cl.cam.ac.uk (user-109-59.vpn.cl.cam.ac.uk [128.232.109.59]) (authenticated bits=0) by theravensnest.org (8.15.2/8.15.2) with ESMTPSA id v619bADU002746 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 1 Jul 2017 09:37:10 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: suggestion for toolchain to have its own directories From: David Chisnall X-Priority: 3 In-Reply-To: Date: Sat, 1 Jul 2017 10:37:09 +0100 Cc: freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sid X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 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, 01 Jul 2017 10:01:29 -0000 On 30 Jun 2017, at 21:35, Sid wrote: >=20 > Wouldn't it make sense for toolchains, compilers and their libraries = to have their own dedicated top level directories like something under = /usr/toolchain/ and /usr/local/toolchain/ in the latest FreeBSD = versions? It would be easier for maintenance, and organization of = compilers and toolchain components. Debian does something like this, and it=E2=80=99s a huge pain to work = with. The problem is that toolchains are not self-contained monolithic = components (though gcc likes to pretend that they are). For example, we = want gcc and clang to use the same linker, the same C and C++ standard = library implementations, and the same system headers, irrespective of = the compiler version. Things that actually are private to a compiler = are in separate directories (see /usr/lib/clang, for example). David