From owner-freebsd-toolchain@freebsd.org Sun Apr 23 18:00:01 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 7D1E3D4D03A for ; Sun, 23 Apr 2017 18:00:01 +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 6CF60FE8 for ; Sun, 23 Apr 2017 18:00:01 +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 v3NI01cp093947 for ; Sun, 23 Apr 2017 18:00:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 217376] make buildworld exits with segfault Date: Sun, 23 Apr 2017 18:00:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.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: assigned_to 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, 23 Apr 2017 18:00:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217376 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Apr 23 18:21: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 A7CBAD4D1C8 for ; Sun, 23 Apr 2017 18:21:32 +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 8E537B29 for ; Sun, 23 Apr 2017 18:21:32 +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 v3NILVtk078236 for ; Sun, 23 Apr 2017 18:21:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 209413] c++ symbolic functions broken on arm Date: Sun, 23 Apr 2017 18:21:31 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.mimetype 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, 23 Apr 2017 18:21:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209413 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #170167|text/x-csrc |text/plain mime type| | --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Apr 23 18:35:22 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 C6A37D4DE0F for ; Sun, 23 Apr 2017 18:35:22 +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 B60211CCB for ; Sun, 23 Apr 2017 18:35:22 +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 v3NIZMGg012051 for ; Sun, 23 Apr 2017 18:35:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 217376] make buildworld exits with segfault Date: Sun, 23 Apr 2017 18:35:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status cc 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, 23 Apr 2017 18:35:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217376 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-toolchain@FreeBSD.o |dim@FreeBSD.org |rg | Status|New |In Progress CC| |dim@FreeBSD.org --- Comment #3 from Dimitry Andric --- I've tried reproducing your error with clang 5.0.0, 4.0.0, 3.9.0, 3.8.0 and 3.7.1, but for me your sample compiles just fine. All these compiles don't take a lot of memory either, so I think we can rule out crashes due to limi= ted RAM. Maybe the /usr/obj/usr/src/tmp/usr/bin/cc executable was built with CPU opt= ions which aren't valid for your hardware? Are you able to get a backtrace and/= or some more detailed debugging information? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Apr 24 23:20: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 3371AD4ED3B for ; Mon, 24 Apr 2017 23:20:59 +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 226A7EC6 for ; Mon, 24 Apr 2017 23:20:59 +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 v3ONKwOV074076 for ; Mon, 24 Apr 2017 23:20:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 218860] libelf doesn't reload section headers after update with ELF_C_WRITE Date: Mon, 24 Apr 2017 23:20:59 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cem@freebsd.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: assigned_to cc 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, 24 Apr 2017 23:20:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218860 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg CC| |cem@freebsd.org, | |emaste@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Apr 24 23:21:52 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 5000ED4EEDA for ; Mon, 24 Apr 2017 23:21:52 +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 3FB01169 for ; Mon, 24 Apr 2017 23:21:52 +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 v3ONLq2t079370 for ; Mon, 24 Apr 2017 23:21:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 218861] libelf elf_update fails when adding sections Date: Mon, 24 Apr 2017 23:21:52 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cem@freebsd.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: assigned_to cc 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, 24 Apr 2017 23:21:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218861 Conrad Meyer changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-toolchain@FreeBSD.o | |rg CC| |cem@freebsd.org, | |emaste@freebsd.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Apr 24 23:27:18 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 0A28BD4EFAA for ; Mon, 24 Apr 2017 23:27:18 +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 EE1EE38C for ; Mon, 24 Apr 2017 23:27: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 v3ONRHEl087978 for ; Mon, 24 Apr 2017 23:27:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 218861] libelf elf_update fails when adding sections Date: Mon, 24 Apr 2017 23:27:18 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emc2@metricspace.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: Mon, 24 Apr 2017 23:27:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218861 --- Comment #1 from Eric McCorkle --- Review for fix: https://reviews.freebsd.org/D10487 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Apr 25 17:54:56 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 6F566D50A80 for ; Tue, 25 Apr 2017 17:54:56 +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 5F155C39 for ; Tue, 25 Apr 2017 17:54:56 +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 v3PHstXU089496 for ; Tue, 25 Apr 2017 17:54:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 218861] libelf elf_update fails when adding sections Date: Tue, 25 Apr 2017 17:54:56 +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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.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: keywords 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: Tue, 25 Apr 2017 17:54:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218861 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Apr 25 17:55:14 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 38CBED50AA9 for ; Tue, 25 Apr 2017 17:55:14 +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 285FFC7C for ; Tue, 25 Apr 2017 17:55:14 +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 v3PHtDWQ090101 for ; Tue, 25 Apr 2017 17:55:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 218860] libelf doesn't reload section headers after update with ELF_C_WRITE Date: Tue, 25 Apr 2017 17:55:14 +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: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.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: keywords 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: Tue, 25 Apr 2017 17:55:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218860 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Apr 26 11:04:20 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 1D634D507A8 for ; Wed, 26 Apr 2017 11:04:20 +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 0CAEADB6 for ; Wed, 26 Apr 2017 11:04:20 +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 v3QB4JM6077096 for ; Wed, 26 Apr 2017 11:04:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 218808] www/firefox: usr/bin/ld: error: unknown argument: --warn-unresolved-symbols Date: Wed, 26 Apr 2017 11:04:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ohartmann@walstatt.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ 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: Wed, 26 Apr 2017 11:04:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218808 --- Comment #3 from O. Hartmann --- (In reply to Jan Beich from comment #2) Is there a solution? www/firefox doesn't build on 12-CURRENT (recent, as of today) anymore if WITH_LLD_IS_LD is enabled. poudriere also fails on the very same error. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Apr 26 17:06:45 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 F0527D51B0E for ; Wed, 26 Apr 2017 17:06:45 +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 DF9DBEC8 for ; Wed, 26 Apr 2017 17:06:45 +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 v3QH6j1W049043 for ; Wed, 26 Apr 2017 17:06:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 217648] [lld 4.0.0] WITH_LLD_IS_LD Results Date: Wed, 26 Apr 2017 17:06:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.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, 26 Apr 2017 17:06:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217648 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org Status|New |Closed Resolution|--- |FIXED --- Comment #4 from Ed Maste --- Thank you for the report. These issues have been fixed in FreeBSD-HEAD and WITH_LLD_IS_LD is now on by default for arm64. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Apr 26 17:08: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 06759D51B44 for ; Wed, 26 Apr 2017 17:08:53 +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 E98D7F1D for ; Wed, 26 Apr 2017 17:08:52 +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 v3QH8q0C051678 for ; Wed, 26 Apr 2017 17:08:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 214971] clang + lld 3.9.1: Unhandled relocation 1031 Date: Wed, 26 Apr 2017 17:08:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10- mfc-stable11? X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.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, 26 Apr 2017 17:08:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214971 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #5 from Ed Maste --- This has been merged to stable/11 now too --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Apr 29 00:24: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 0B419D55AF2 for ; Sat, 29 Apr 2017 00:24:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 C5164A12 for ; Sat, 29 Apr 2017 00:24:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27601 invoked from network); 29 Apr 2017 00:27:42 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Apr 2017 00:27:42 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 28 Apr 2017 20:24:28 -0400 (EDT) Received: (qmail 26265 invoked from network); 29 Apr 2017 00:24:28 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Apr 2017 00:24:28 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0EFE3EC913D; Fri, 28 Apr 2017 17:24:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc From: Mark Millard In-Reply-To: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> Date: Fri, 28 Apr 2017 17:24:27 -0700 Cc: Baptiste Daroussin , Alexander Kabaev Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> To: svn-ports-head@freebsd.org, Mark Linimon , FreeBSD Toolchain 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, 29 Apr 2017 00:24:31 -0000 On 2017-Apr-28, at 3:27 PM, Mark Millard wrote: > Just FYI: >=20 > https://reviews.freebsd.org/D10537 may help with powerpc64-gcc > slave ports (and powerpc64-gcc itself) when they are built on > the type of machine that they target. >=20 > As of devel/*binutils -r436732 and -r432733 (the update > to 2.28) many things are broken for linking with debug > information that were not before (for example). It turns > out to be because of a change in return code for reporting > issues for the cases I know about: the new return code > stops the build (and the return code is likely appropriate > long term as I understand). For example a formerly ignored > debug information issue now blocks various builds when a > (modern) binutils is involved. >=20 > [Because of this I've been reverting devel/*binutils > to -r436731 each time I update the revision of > /usr/ports.] >=20 > As of ports head -r439263 with reverting > devel/*binutils to -r436731 and the patch > from D10537 I tested building the following > earlier today as part of reviewing D10537: >=20 > amd64: built amd64-gcc powerpc64-gcc aarch64-gcc > powerpc64: built powerpc64-gcc > aarch64: built aarch64-gcc > (Note: aarch64 is using -mcpu=3Dcortex-a53 explicitly.) >=20 > Context: head -r317015 in each case. > (WITH_LLD_IS_LD=3D was used on aarch64.) > (powerpc64 is system-clang/libc++ based, used > devel/*binutils) >=20 > If the information would be useful I could try > some other combinations under the patch and > the older binutils for comparison. (That does > not say when anyone might use the information.) >=20 > I also have access to armv7. (In this context > I normally use -mcpu=3Dcortex-a7 explicitly.) > So I could try that type of host as well. >=20 > I do not have access to mips, mips64, riscv, sparc64 > so they could be targets but not hosts in my tests: > always cross-builds. >=20 > I have access to powerpc but currently am not well > set up to use it without rebuilding it as gcc 4.2.1 > based for buildworld, not just buildkernel. (clang > generates bad stack handling for some contexts for > 32-bit powerpc.) I tried building devel/amd64-gcc on a powerpc64 head -r317015 system that was built with clang and libc++ and has clang as its system compiler. /usr/ports as of -r439263 but devel/*binutils as of -r436731 (so 2.27 instead of 2.2.8). The result was the "=3Da" problem for the clang based build: = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:223:3: error: invalid output constraint '=3Da' in asm __cpuid (__ext, __eax, __ebx, __ecx, __edx); ^ = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ . . . (other such messages) . . . In file included from = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/co= nfig/i386/driver-i386.c:554::225: error: invalid output constraint '=3Da' = in asm . . . : "=3Da" (eax), "=3Dd" (edx) ^ . . . So this system-clang context on powerpc64 is like -r439595 reports for building devel/amd64-gcc on aarch64: +BROKEN_aarch64=3D error: invalid output constraint '=3Da' = in asm head/devel/amd64-gcc/Makefile only says: BROKEN_powerpc64=3D Does not build but it is like on aarch64 --at least when system-clang compiler that is in use. The compiler command lines were: c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libba= cktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT = driver-i386.o -MMD -MP -MF ./.deps/driver-i386.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic-family = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family= = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libba= cktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o c-family/cppspec.o -MT = c-family/cppspec.o -MMD -MP -MF c-family/.deps/cppspec.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c It will be a fairly long time before the aarch64 context gets to this point in a devel/adm64-gcc build, although I expect a replication of the reported behavior for building devel/amd64-gcc . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 29 01:10:54 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 7BEEED52919 for ; Sat, 29 Apr 2017 01:10:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 33A861C8 for ; Sat, 29 Apr 2017 01:10:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3018 invoked from network); 29 Apr 2017 01:10:52 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Apr 2017 01:10:52 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 28 Apr 2017 21:10:52 -0400 (EDT) Received: (qmail 18188 invoked from network); 29 Apr 2017 01:10:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Apr 2017 01:10:52 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D26F8EC7ED9; Fri, 28 Apr 2017 18:10:51 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc From: Mark Millard In-Reply-To: Date: Fri, 28 Apr 2017 18:10:51 -0700 Cc: Alexander Kabaev Content-Transfer-Encoding: quoted-printable Message-Id: <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> To: svn-ports-head@freebsd.org, Mark Linimon , FreeBSD Toolchain 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, 29 Apr 2017 01:10:54 -0000 On 2017-Apr-28, at 5:24 PM, Mark Millard wrote: > On 2017-Apr-28, at 3:27 PM, Mark Millard = wrote: >=20 >> Just FYI: >>=20 >> https://reviews.freebsd.org/D10537 may help with powerpc64-gcc >> slave ports (and powerpc64-gcc itself) when they are built on >> the type of machine that they target. >>=20 >> As of devel/*binutils -r436732 and -r432733 (the update >> to 2.28) many things are broken for linking with debug >> information that were not before (for example). It turns >> out to be because of a change in return code for reporting >> issues for the cases I know about: the new return code >> stops the build (and the return code is likely appropriate >> long term as I understand). For example a formerly ignored >> debug information issue now blocks various builds when a >> (modern) binutils is involved. >>=20 >> [Because of this I've been reverting devel/*binutils >> to -r436731 each time I update the revision of >> /usr/ports.] >>=20 >> As of ports head -r439263 with reverting >> devel/*binutils to -r436731 and the patch >> from D10537 I tested building the following >> earlier today as part of reviewing D10537: >>=20 >> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc >> powerpc64: built powerpc64-gcc >> aarch64: built aarch64-gcc >> (Note: aarch64 is using -mcpu=3Dcortex-a53 explicitly.) >>=20 >> Context: head -r317015 in each case. >> (WITH_LLD_IS_LD=3D was used on aarch64.) >> (powerpc64 is system-clang/libc++ based, used >> devel/*binutils) >>=20 >> If the information would be useful I could try >> some other combinations under the patch and >> the older binutils for comparison. (That does >> not say when anyone might use the information.) >>=20 >> I also have access to armv7. (In this context >> I normally use -mcpu=3Dcortex-a7 explicitly.) >> So I could try that type of host as well. >>=20 >> I do not have access to mips, mips64, riscv, sparc64 >> so they could be targets but not hosts in my tests: >> always cross-builds. >>=20 >> I have access to powerpc but currently am not well >> set up to use it without rebuilding it as gcc 4.2.1 >> based for buildworld, not just buildkernel. (clang >> generates bad stack handling for some contexts for >> 32-bit powerpc.) >=20 > I tried building devel/amd64-gcc on a powerpc64 > head -r317015 system that was built with clang > and libc++ and has clang as its system compiler. > /usr/ports as of -r439263 but devel/*binutils as > of -r436731 (so 2.27 instead of 2.2.8). The result > was the "=3Da" problem for the clang based build: >=20 > = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:223:3: error: invalid output constraint '=3Da' in asm > __cpuid (__ext, __eax, __ebx, __ecx, __edx); > ^ > = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' > : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ > . . . (other such messages) . . . > In file included from = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/co= nfig/i386/driver-i386.c:554::225: error: invalid output constraint '=3Da' = in asm > . . . > : "=3Da" (eax), "=3Dd" (edx) > ^ > . . . >=20 > So this system-clang context on powerpc64 is like -r439595 > reports for building devel/amd64-gcc on aarch64: >=20 > +BROKEN_aarch64=3D error: invalid output constraint '=3Da' = in asm >=20 > head/devel/amd64-gcc/Makefile only says: >=20 > BROKEN_powerpc64=3D Does not build >=20 > but it is like on aarch64 --at least when system-clang > compiler that is in use. >=20 > The compiler command lines were: >=20 > c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libba= ckt > race -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT = driver-i386.o -MMD -MP -MF ./.deps/driver-i386.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c >=20 > c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic-family = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family= = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/g > cc/../libbacktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o = c-family/cppspec.o -MT c-family/cppspec.o -MMD -MP -MF = c-family/.deps/cppspec.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c >=20 > It will be a fairly long time before the aarch64 > context gets to this point in a devel/adm64-gcc > build, although I expect a replication of the > reported behavior for building devel/amd64-gcc . Based on the aarch64 context specified in the original note (system version, /usr/ports versions, and the like). . . The following built fine: =3D=3D=3D>>> The following actions were performed: Re-installation of aarch64-none-elf-gcc-6.3.0 Installation of devel/arm-none-eabi-binutils = (arm-none-eabi-binutils-2.27_5,1) Installation of devel/arm-none-eabi-gcc = (arm-none-eabi-gcc-6.3.0) But devel/arm-none-eabi-gcc492 then conflicts with devel/arm-none-eabi-gcc : =3D=3D=3D> Registering installation for arm-none-eabi-gcc492-4.9.2_2 Installing arm-none-eabi-gcc492-4.9.2_2... pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ *** Error code 70 So to test devel/arm-none-eabi-gcc492 fully requires that any pre-installed devel/arm-none-eabi-gcc first be deleted/removed. There is every indication that absent the conflict devel/arm-none-eabi-gcc492 would have installed just fine and it did build to the point of installing. So the following did not have package problems: devel/aarch64-none-elf-gcc-6.3.0 devel/arm-none-eabi-gcc But that last was given that devel/arm-none-eabi-gcc492 had not been installed. I still have the following to go on aarch64 (cortex-a53): devel/powerpc64-gcc devel/riscv64-gcc devel/sparc64-gcc devel/amd64-gcc I also have armv7 (cortex-a7) attempting: devel/arm-none-eabi-gcc492 devel/amd64-gcc =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 29 02:15:09 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 1F89DD546F5 for ; Sat, 29 Apr 2017 02:15:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-50.reflexion.net [208.70.210.50]) (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 D1E0A1D54 for ; Sat, 29 Apr 2017 02:15:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8976 invoked from network); 29 Apr 2017 02:16:14 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Apr 2017 02:16:14 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 28 Apr 2017 22:15:06 -0400 (EDT) Received: (qmail 19164 invoked from network); 29 Apr 2017 02:15:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Apr 2017 02:15:06 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C0BB2EC7C30; Fri, 28 Apr 2017 19:15:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc From: Mark Millard In-Reply-To: <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> Date: Fri, 28 Apr 2017 19:15:05 -0700 Cc: Alexander Kabaev Content-Transfer-Encoding: quoted-printable Message-Id: <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net> References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> To: svn-ports-head@freebsd.org, Mark Linimon , FreeBSD Toolchain 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, 29 Apr 2017 02:15:09 -0000 On 2017-Apr-28, at 6:10 PM, Mark Millard wrote: > On 2017-Apr-28, at 5:24 PM, Mark Millard = wrote: >=20 >> On 2017-Apr-28, at 3:27 PM, Mark Millard = wrote: >>=20 >>> Just FYI: >>>=20 >>> https://reviews.freebsd.org/D10537 may help with powerpc64-gcc >>> slave ports (and powerpc64-gcc itself) when they are built on >>> the type of machine that they target. >>>=20 >>> As of devel/*binutils -r436732 and -r432733 (the update >>> to 2.28) many things are broken for linking with debug >>> information that were not before (for example). It turns >>> out to be because of a change in return code for reporting >>> issues for the cases I know about: the new return code >>> stops the build (and the return code is likely appropriate >>> long term as I understand). For example a formerly ignored >>> debug information issue now blocks various builds when a >>> (modern) binutils is involved. >>>=20 >>> [Because of this I've been reverting devel/*binutils >>> to -r436731 each time I update the revision of >>> /usr/ports.] >>>=20 >>> As of ports head -r439263 with reverting >>> devel/*binutils to -r436731 and the patch >>> from D10537 I tested building the following >>> earlier today as part of reviewing D10537: >>>=20 >>> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc >>> powerpc64: built powerpc64-gcc >>> aarch64: built aarch64-gcc >>> (Note: aarch64 is using -mcpu=3Dcortex-a53 explicitly.) >>>=20 >>> Context: head -r317015 in each case. >>> (WITH_LLD_IS_LD=3D was used on aarch64.) >>> (powerpc64 is system-clang/libc++ based, used >>> devel/*binutils) >>>=20 >>> If the information would be useful I could try >>> some other combinations under the patch and >>> the older binutils for comparison. (That does >>> not say when anyone might use the information.) >>>=20 >>> I also have access to armv7. (In this context >>> I normally use -mcpu=3Dcortex-a7 explicitly.) >>> So I could try that type of host as well. >>>=20 >>> I do not have access to mips, mips64, riscv, sparc64 >>> so they could be targets but not hosts in my tests: >>> always cross-builds. >>>=20 >>> I have access to powerpc but currently am not well >>> set up to use it without rebuilding it as gcc 4.2.1 >>> based for buildworld, not just buildkernel. (clang >>> generates bad stack handling for some contexts for >>> 32-bit powerpc.) >>=20 >> I tried building devel/amd64-gcc on a powerpc64 >> head -r317015 system that was built with clang >> and libc++ and has clang as its system compiler. >> /usr/ports as of -r439263 but devel/*binutils as >> of -r436731 (so 2.27 instead of 2.2.8). The result >> was the "=3Da" problem for the clang based build: >>=20 >> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:223:3: error: invalid output constraint '=3Da' in asm >> __cpuid (__ext, __eax, __ebx, __ecx, __edx); >> ^ >> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' >> : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ >> . . . (other such messages) . . . >> In file included from = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/co= nfig/i386/driver-i386.c:554::225: error: invalid output constraint '=3Da' = in asm >> . . . >> : "=3Da" (eax), "=3Dd" (edx) >> ^ >> . . . >>=20 >> So this system-clang context on powerpc64 is like -r439595 >> reports for building devel/amd64-gcc on aarch64: >>=20 >> +BROKEN_aarch64=3D error: invalid output constraint '=3Da' = in asm >>=20 >> head/devel/amd64-gcc/Makefile only says: >>=20 >> BROKEN_powerpc64=3D Does not build >>=20 >> but it is like on aarch64 --at least when system-clang >> compiler that is in use. >>=20 >> The compiler command lines were: >>=20 >> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libba= c > kt >> race -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT = driver-i386.o -MMD -MP -MF ./.deps/driver-i386.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c >>=20 >> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic-family = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family= = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0 > /g >> cc/../libbacktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o = c-family/cppspec.o -MT c-family/cppspec.o -MMD -MP -MF = c-family/.deps/cppspec.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c >>=20 >> It will be a fairly long time before the aarch64 >> context gets to this point in a devel/adm64-gcc >> build, although I expect a replication of the >> reported behavior for building devel/amd64-gcc . >=20 > Based on the aarch64 context specified in the > original note (system version, /usr/ports versions, > and the like). . . >=20 > The following built fine: >=20 > =3D=3D=3D>>> The following actions were performed: > Re-installation of aarch64-none-elf-gcc-6.3.0 > Installation of devel/arm-none-eabi-binutils = (arm-none-eabi-binutils-2.27_5,1) > Installation of devel/arm-none-eabi-gcc = (arm-none-eabi-gcc-6.3.0) >=20 > But devel/arm-none-eabi-gcc492 then conflicts with > devel/arm-none-eabi-gcc : >=20 > =3D=3D=3D> Registering installation for arm-none-eabi-gcc492-4.9.2_2 > Installing arm-none-eabi-gcc492-4.9.2_2... > pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ > *** Error code 70 >=20 > So to test devel/arm-none-eabi-gcc492 fully requires that > any pre-installed devel/arm-none-eabi-gcc first be > deleted/removed. >=20 > There is every indication that absent the conflict > devel/arm-none-eabi-gcc492 would have installed just > fine and it did build to the point of installing. >=20 > So the following did not have package problems: >=20 > devel/aarch64-none-elf-gcc-6.3.0 > devel/arm-none-eabi-gcc >=20 > But that last was given that devel/arm-none-eabi-gcc492 > had not been installed. >=20 >=20 > I still have the following to go on aarch64 (cortex-a53): >=20 > devel/powerpc64-gcc > devel/riscv64-gcc > devel/sparc64-gcc > devel/amd64-gcc >=20 > I also have armv7 (cortex-a7) attempting: >=20 > devel/arm-none-eabi-gcc492 > devel/amd64-gcc The armv7 attempt at devel/amd64-gcc also got the "=3Da" problem, such as: = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c:608:2: error: invalid output constraint '=3Da' in asm __cpuid (0x80000002, name, ebx, ecx, edx); ^ = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ ^ So this is like what devel/powerpc64-gcc got in a system-clang based context --and armv7 is again based on clang so the message is from clang. (I expect aarch64 to get the same thing once it tries devel/amd64-gcc since -r439595 reports such for aarch64.) Not that this is different from -r439595's report, which said for devel/amd64-gcc: +BROKEN_armv6=3D fails to package Since the compile problem would before any package attempt I've no clue how -r439595 got as far as package if it was using clang to do the build. armv7 still has devel/arm-none-eabi-gcc492 to go. aarch64 is working on: devel/powerpc64-gcc devel/riscv64-gcc devel/sparc64-gcc devel/amd64-gcc =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 29 02:29: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 1AAB1D54A59; Sat, 29 Apr 2017 02:29:35 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D1AF1304; Sat, 29 Apr 2017 02:29:34 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 35DF326DB; Fri, 28 Apr 2017 21:29:29 -0500 (CDT) Date: Fri, 28 Apr 2017 21:29:28 -0500 From: Mark Linimon To: Mark Millard Cc: svn-ports-head@freebsd.org, FreeBSD Toolchain , Baptiste Daroussin , Alexander Kabaev Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc Message-ID: <20170429022927.GC15674@lonesome.com> References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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, 29 Apr 2017 02:29:35 -0000 On Fri, Apr 28, 2017 at 05:24:27PM -0700, Mark Millard wrote: > BROKEN_powerpc64= Does not build I'm attempting builds now. The message is from the last time it was tried, many months ago. mcl From owner-freebsd-toolchain@freebsd.org Sat Apr 29 02:34: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 837F0D54C7E; Sat, 29 Apr 2017 02:34:05 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "StartCom Class 2 IV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 63E1F8B7; Sat, 29 Apr 2017 02:34:05 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id 5CDEC26DB; Fri, 28 Apr 2017 21:34:04 -0500 (CDT) Date: Fri, 28 Apr 2017 21:34:03 -0500 From: Mark Linimon To: Mark Millard Cc: svn-ports-head@freebsd.org, FreeBSD Toolchain , Alexander Kabaev Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc Message-ID: <20170429023403.GD15674@lonesome.com> References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 29 Apr 2017 02:34:05 -0000 On Fri, Apr 28, 2017 at 07:15:05PM -0700, Mark Millard wrote: > The armv7 attempt at devel/amd64-gcc also got > the "=a" problem, such as: > > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/driver-i386.c:608:2: error: invalid output constraint '=a' in asm > __cpuid (0x80000002, name, ebx, ecx, edx); > ^ > /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i386/cpuid.h:165:7: note: expanded from macro '__cpuid' > : "=a" (a), "=b" (b), "=c" (c), "=d" (d) \ > ^ > > Note that this is different from -r439595's > report, which said for devel/amd64-gcc: > > +BROKEN_armv6= fails to package The latest build log seems to confirm this: http://beefy8.nyi.freebsd.org/data/head-armv6-default/p438916_s317177/logs/errors/amd64-gcc-6.3.0.log It's likely I simply made a mistake in transcription. mcl From owner-freebsd-toolchain@freebsd.org Sat Apr 29 03:40:14 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 5D331D55B10 for ; Sat, 29 Apr 2017 03:40:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 21836954 for ; Sat, 29 Apr 2017 03:40:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29847 invoked from network); 29 Apr 2017 03:40:12 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Apr 2017 03:40:12 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 28 Apr 2017 23:40:12 -0400 (EDT) Received: (qmail 2469 invoked from network); 29 Apr 2017 03:40:11 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Apr 2017 03:40:11 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 21202EC7ED9; Fri, 28 Apr 2017 20:40:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc From: Mark Millard In-Reply-To: <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net> Date: Fri, 28 Apr 2017 20:40:10 -0700 Cc: Alexander Kabaev Content-Transfer-Encoding: quoted-printable Message-Id: <1E21DD74-6F0E-4D60-8595-95BFDEC0884B@dsl-only.net> References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net> To: svn-ports-head@freebsd.org, Mark Linimon , FreeBSD Toolchain 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, 29 Apr 2017 03:40:14 -0000 On 2017-Apr-28, at 7:15 PM, Mark Millard wrote: > On 2017-Apr-28, at 6:10 PM, Mark Millard = wrote: >=20 >> On 2017-Apr-28, at 5:24 PM, Mark Millard = wrote: >>=20 >>> On 2017-Apr-28, at 3:27 PM, Mark Millard = wrote: >>>=20 >>>> Just FYI: >>>>=20 >>>> https://reviews.freebsd.org/D10537 may help with powerpc64-gcc >>>> slave ports (and powerpc64-gcc itself) when they are built on >>>> the type of machine that they target. >>>>=20 >>>> As of devel/*binutils -r436732 and -r432733 (the update >>>> to 2.28) many things are broken for linking with debug >>>> information that were not before (for example). It turns >>>> out to be because of a change in return code for reporting >>>> issues for the cases I know about: the new return code >>>> stops the build (and the return code is likely appropriate >>>> long term as I understand). For example a formerly ignored >>>> debug information issue now blocks various builds when a >>>> (modern) binutils is involved. >>>>=20 >>>> [Because of this I've been reverting devel/*binutils >>>> to -r436731 each time I update the revision of >>>> /usr/ports.] >>>>=20 >>>> As of ports head -r439263 with reverting >>>> devel/*binutils to -r436731 and the patch >>>> from D10537 I tested building the following >>>> earlier today as part of reviewing D10537: >>>>=20 >>>> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc >>>> powerpc64: built powerpc64-gcc >>>> aarch64: built aarch64-gcc >>>> (Note: aarch64 is using -mcpu=3Dcortex-a53 explicitly.) >>>>=20 >>>> Context: head -r317015 in each case. >>>> (WITH_LLD_IS_LD=3D was used on aarch64.) >>>> (powerpc64 is system-clang/libc++ based, used >>>> devel/*binutils) >>>>=20 >>>> If the information would be useful I could try >>>> some other combinations under the patch and >>>> the older binutils for comparison. (That does >>>> not say when anyone might use the information.) >>>>=20 >>>> I also have access to armv7. (In this context >>>> I normally use -mcpu=3Dcortex-a7 explicitly.) >>>> So I could try that type of host as well. >>>>=20 >>>> I do not have access to mips, mips64, riscv, sparc64 >>>> so they could be targets but not hosts in my tests: >>>> always cross-builds. >>>>=20 >>>> I have access to powerpc but currently am not well >>>> set up to use it without rebuilding it as gcc 4.2.1 >>>> based for buildworld, not just buildkernel. (clang >>>> generates bad stack handling for some contexts for >>>> 32-bit powerpc.) >>>=20 >>> I tried building devel/amd64-gcc on a powerpc64 >>> head -r317015 system that was built with clang >>> and libc++ and has clang as its system compiler. >>> /usr/ports as of -r439263 but devel/*binutils as >>> of -r436731 (so 2.27 instead of 2.2.8). The result >>> was the "=3Da" problem for the clang based build: >>>=20 >>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:223:3: error: invalid output constraint '=3Da' in asm >>> __cpuid (__ext, __eax, __ebx, __ecx, __edx); >>> ^ >>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' >>> : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ >>> . . . (other such messages) . . . >>> In file included from = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/co= nfig/i386/driver-i386.c:554::225: error: invalid output constraint '=3Da' = in asm >>> . . . >>> : "=3Da" (eax), "=3Dd" (edx) >>> ^ >>> . . . >>>=20 >>> So this system-clang context on powerpc64 is like -r439595 >>> reports for building devel/amd64-gcc on aarch64: >>>=20 >>> +BROKEN_aarch64=3D error: invalid output constraint '=3Da' = in asm >>>=20 >>> head/devel/amd64-gcc/Makefile only says: >>>=20 >>> BROKEN_powerpc64=3D Does not build >>>=20 >>> but it is like on aarch64 --at least when system-clang >>> compiler that is in use. >>>=20 >>> The compiler command lines were: >>>=20 >>> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libba= c >> kt >>> race -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT = driver-i386.o -MMD -MP -MF ./.deps/driver-i386.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c >>>=20 >>> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic-family = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family= = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0 >> /g >>> cc/../libbacktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o = c-family/cppspec.o -MT c-family/cppspec.o -MMD -MP -MF = c-family/.deps/cppspec.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c >>>=20 >>> It will be a fairly long time before the aarch64 >>> context gets to this point in a devel/adm64-gcc >>> build, although I expect a replication of the >>> reported behavior for building devel/amd64-gcc . >>=20 >> Based on the aarch64 context specified in the >> original note (system version, /usr/ports versions, >> and the like). . . >>=20 >> The following built fine: >>=20 >> =3D=3D=3D>>> The following actions were performed: >> Re-installation of aarch64-none-elf-gcc-6.3.0 >> Installation of devel/arm-none-eabi-binutils = (arm-none-eabi-binutils-2.27_5,1) >> Installation of devel/arm-none-eabi-gcc = (arm-none-eabi-gcc-6.3.0) >>=20 >> But devel/arm-none-eabi-gcc492 then conflicts with >> devel/arm-none-eabi-gcc : >>=20 >> =3D=3D=3D> Registering installation for = arm-none-eabi-gcc492-4.9.2_2 >> Installing arm-none-eabi-gcc492-4.9.2_2... >> pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ >> *** Error code 70 >>=20 >> So to test devel/arm-none-eabi-gcc492 fully requires that >> any pre-installed devel/arm-none-eabi-gcc first be >> deleted/removed. >>=20 >> There is every indication that absent the conflict >> devel/arm-none-eabi-gcc492 would have installed just >> fine and it did build to the point of installing. >>=20 >> So the following did not have package problems: >>=20 >> devel/aarch64-none-elf-gcc-6.3.0 >> devel/arm-none-eabi-gcc >>=20 >> But that last was given that devel/arm-none-eabi-gcc492 >> had not been installed. >>=20 >>=20 >> I still have the following to go on aarch64 (cortex-a53): >>=20 >> devel/powerpc64-gcc >> devel/riscv64-gcc >> devel/sparc64-gcc >> devel/amd64-gcc >>=20 >> I also have armv7 (cortex-a7) attempting: >>=20 >> devel/arm-none-eabi-gcc492 >> devel/amd64-gcc >=20 > The armv7 attempt at devel/amd64-gcc also got > the "=3Da" problem, such as: >=20 > = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c:608:2: error: invalid output constraint '=3Da' in asm > __cpuid (0x80000002, name, ebx, ecx, edx); > ^ > = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' > : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ > ^ >=20 > So this is like what devel/powerpc64-gcc got in a > system-clang based context --and armv7 is again > based on clang so the message is from clang. (I > expect aarch64 to get the same thing once it > tries devel/amd64-gcc since -r439595 reports > such for aarch64.) >=20 > Not that this is different from -r439595's > report, which said for devel/amd64-gcc: >=20 > +BROKEN_armv6=3D fails to package >=20 > Since the compile problem would before any > package attempt I've no clue how -r439595 > got as far as package if it was using clang > to do the build. >=20 > armv7 still has devel/arm-none-eabi-gcc492 to go. >=20 > aarch64 is working on: >=20 > devel/powerpc64-gcc > devel/riscv64-gcc > devel/sparc64-gcc > devel/amd64-gcc The armv7 attempt at devel/arm-none-eabi-gcc492 also got the conflict with devel/arm-none-eabi-gcc : =3D=3D=3D> Registering installation for arm-none-eabi-gcc492-4.9.2_2 Installing arm-none-eabi-gcc492-4.9.2_2... pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ *** Error code 70 Note that this is different than the -r439595 report: +BROKEN_armv6=3D error: no member named 'fancy_abort' in = namespace 'std::__1'; did you mean simply 'fancy_abort'? I've no clue what caused the "fancy_abort" problem reported in -r439595 . Only one of: devel/arm-none-eabi-gcc vs. devel/arm-none-eabi-gcc492 can be installed at a time and to install one required removal/deletion of the other first (if it already exists). Other than the conflict everything looks to have worked up to trying to actually install. I expect aarch64's attempt at devel/aarch64-gcc to do the same sort of thing. aarch64 is still working on: devel/powerpc64-gcc devel/riscv64-gcc devel/sparc64-gcc devel/amd64-gcc (It has made it to devel/sparc64 , having installed devel/powerpc64-gcc and devel/riscv64-gcc . No package failures but I'm using D10537's patch and I'm using head -r317015 and other details which are likely different from what -r439595 was based on.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 29 05:59: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 7D89FD55B15 for ; Sat, 29 Apr 2017 05:59:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 40701D54 for ; Sat, 29 Apr 2017 05:59:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27249 invoked from network); 29 Apr 2017 05:59:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Apr 2017 05:59:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 29 Apr 2017 01:59:10 -0400 (EDT) Received: (qmail 2619 invoked from network); 29 Apr 2017 05:59:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Apr 2017 05:59:09 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 178C3EC81E7; Fri, 28 Apr 2017 22:59:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc From: Mark Millard In-Reply-To: <1E21DD74-6F0E-4D60-8595-95BFDEC0884B@dsl-only.net> Date: Fri, 28 Apr 2017 22:59:08 -0700 Cc: Alexander Kabaev Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net> <1E21DD74-6F0E-4D60-8595-95BFDEC0884B@dsl-only.net> To: svn-ports-head@freebsd.org, Mark Linimon , FreeBSD Toolchain 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, 29 Apr 2017 05:59:12 -0000 On 2017-Apr-28, at 8:40 PM, Mark Millard wrote: > On 2017-Apr-28, at 7:15 PM, Mark Millard = wrote: >=20 >> On 2017-Apr-28, at 6:10 PM, Mark Millard = wrote: >>=20 >>> On 2017-Apr-28, at 5:24 PM, Mark Millard = wrote: >>>=20 >>>> On 2017-Apr-28, at 3:27 PM, Mark Millard = wrote: >>>>=20 >>>>> Just FYI: >>>>>=20 >>>>> https://reviews.freebsd.org/D10537 may help with powerpc64-gcc >>>>> slave ports (and powerpc64-gcc itself) when they are built on >>>>> the type of machine that they target. >>>>>=20 >>>>> As of devel/*binutils -r436732 and -r432733 (the update >>>>> to 2.28) many things are broken for linking with debug >>>>> information that were not before (for example). It turns >>>>> out to be because of a change in return code for reporting >>>>> issues for the cases I know about: the new return code >>>>> stops the build (and the return code is likely appropriate >>>>> long term as I understand). For example a formerly ignored >>>>> debug information issue now blocks various builds when a >>>>> (modern) binutils is involved. >>>>>=20 >>>>> [Because of this I've been reverting devel/*binutils >>>>> to -r436731 each time I update the revision of >>>>> /usr/ports.] >>>>>=20 >>>>> As of ports head -r439263 with reverting >>>>> devel/*binutils to -r436731 and the patch >>>>> from D10537 I tested building the following >>>>> earlier today as part of reviewing D10537: >>>>>=20 >>>>> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc >>>>> powerpc64: built powerpc64-gcc >>>>> aarch64: built aarch64-gcc >>>>> (Note: aarch64 is using -mcpu=3Dcortex-a53 explicitly.) >>>>>=20 >>>>> Context: head -r317015 in each case. >>>>> (WITH_LLD_IS_LD=3D was used on aarch64.) >>>>> (powerpc64 is system-clang/libc++ based, used >>>>> devel/*binutils) >>>>>=20 >>>>> If the information would be useful I could try >>>>> some other combinations under the patch and >>>>> the older binutils for comparison. (That does >>>>> not say when anyone might use the information.) >>>>>=20 >>>>> I also have access to armv7. (In this context >>>>> I normally use -mcpu=3Dcortex-a7 explicitly.) >>>>> So I could try that type of host as well. >>>>>=20 >>>>> I do not have access to mips, mips64, riscv, sparc64 >>>>> so they could be targets but not hosts in my tests: >>>>> always cross-builds. >>>>>=20 >>>>> I have access to powerpc but currently am not well >>>>> set up to use it without rebuilding it as gcc 4.2.1 >>>>> based for buildworld, not just buildkernel. (clang >>>>> generates bad stack handling for some contexts for >>>>> 32-bit powerpc.) >>>>=20 >>>> I tried building devel/amd64-gcc on a powerpc64 >>>> head -r317015 system that was built with clang >>>> and libc++ and has clang as its system compiler. >>>> /usr/ports as of -r439263 but devel/*binutils as >>>> of -r436731 (so 2.27 instead of 2.2.8). The result >>>> was the "=3Da" problem for the clang based build: >>>>=20 >>>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:223:3: error: invalid output constraint '=3Da' in asm >>>> __cpuid (__ext, __eax, __ebx, __ecx, __edx); >>>> ^ >>>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' >>>> : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ >>>> . . . (other such messages) . . . >>>> In file included from = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/co= nfig/i386/driver-i386.c:554::225: error: invalid output constraint '=3Da' = in asm >>>> . . . >>>> : "=3Da" (eax), "=3Dd" (edx) >>>> ^ >>>> . . . >>>>=20 >>>> So this system-clang context on powerpc64 is like -r439595 >>>> reports for building devel/amd64-gcc on aarch64: >>>>=20 >>>> +BROKEN_aarch64=3D error: invalid output constraint '=3Da' = in asm >>>>=20 >>>> head/devel/amd64-gcc/Makefile only says: >>>>=20 >>>> BROKEN_powerpc64=3D Does not build >>>>=20 >>>> but it is like on aarch64 --at least when system-clang >>>> compiler that is in use. >>>>=20 >>>> The compiler command lines were: >>>>=20 >>>> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libb > ac >>> kt >>>> race -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT = driver-i386.o -MMD -MP -MF ./.deps/driver-i386.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c >>>>=20 >>>> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic-family = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family= = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3 > .0 >>> /g >>>> cc/../libbacktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o = c-family/cppspec.o -MT c-family/cppspec.o -MMD -MP -MF = c-family/.deps/cppspec.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c >>>>=20 >>>> It will be a fairly long time before the aarch64 >>>> context gets to this point in a devel/adm64-gcc >>>> build, although I expect a replication of the >>>> reported behavior for building devel/amd64-gcc . >>>=20 >>> Based on the aarch64 context specified in the >>> original note (system version, /usr/ports versions, >>> and the like). . . >>>=20 >>> The following built fine: >>>=20 >>> =3D=3D=3D>>> The following actions were performed: >>> Re-installation of aarch64-none-elf-gcc-6.3.0 >>> Installation of devel/arm-none-eabi-binutils = (arm-none-eabi-binutils-2.27_5,1) >>> Installation of devel/arm-none-eabi-gcc = (arm-none-eabi-gcc-6.3.0) >>>=20 >>> But devel/arm-none-eabi-gcc492 then conflicts with >>> devel/arm-none-eabi-gcc : >>>=20 >>> =3D=3D=3D> Registering installation for = arm-none-eabi-gcc492-4.9.2_2 >>> Installing arm-none-eabi-gcc492-4.9.2_2... >>> pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ >>> *** Error code 70 >>>=20 >>> So to test devel/arm-none-eabi-gcc492 fully requires that >>> any pre-installed devel/arm-none-eabi-gcc first be >>> deleted/removed. >>>=20 >>> There is every indication that absent the conflict >>> devel/arm-none-eabi-gcc492 would have installed just >>> fine and it did build to the point of installing. >>>=20 >>> So the following did not have package problems: >>>=20 >>> devel/aarch64-none-elf-gcc-6.3.0 >>> devel/arm-none-eabi-gcc >>>=20 >>> But that last was given that devel/arm-none-eabi-gcc492 >>> had not been installed. >>>=20 >>>=20 >>> I still have the following to go on aarch64 (cortex-a53): >>>=20 >>> devel/powerpc64-gcc >>> devel/riscv64-gcc >>> devel/sparc64-gcc >>> devel/amd64-gcc >>>=20 >>> I also have armv7 (cortex-a7) attempting: >>>=20 >>> devel/arm-none-eabi-gcc492 >>> devel/amd64-gcc >>=20 >> The armv7 attempt at devel/amd64-gcc also got >> the "=3Da" problem, such as: >>=20 >> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c:608:2: error: invalid output constraint '=3Da' in asm >> __cpuid (0x80000002, name, ebx, ecx, edx); >> ^ >> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' >> : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ >> ^ >>=20 >> So this is like what devel/powerpc64-gcc got in a >> system-clang based context --and armv7 is again >> based on clang so the message is from clang. (I >> expect aarch64 to get the same thing once it >> tries devel/amd64-gcc since -r439595 reports >> such for aarch64.) >>=20 >> Not that this is different from -r439595's >> report, which said for devel/amd64-gcc: >>=20 >> +BROKEN_armv6=3D fails to package >>=20 >> Since the compile problem would before any >> package attempt I've no clue how -r439595 >> got as far as package if it was using clang >> to do the build. >>=20 >> armv7 still has devel/arm-none-eabi-gcc492 to go. >>=20 >> aarch64 is working on: >>=20 >> devel/powerpc64-gcc >> devel/riscv64-gcc >> devel/sparc64-gcc >> devel/amd64-gcc >=20 > The armv7 attempt at devel/arm-none-eabi-gcc492 also > got the conflict with devel/arm-none-eabi-gcc : >=20 > =3D=3D=3D> Registering installation for arm-none-eabi-gcc492-4.9.2_2 > Installing arm-none-eabi-gcc492-4.9.2_2... > pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ > *** Error code 70 >=20 > Note that this is different than the -r439595 > report: >=20 > +BROKEN_armv6=3D error: no member named 'fancy_abort' in = namespace 'std::__1'; did you mean simply 'fancy_abort'? >=20 > I've no clue what caused the "fancy_abort" problem > reported in -r439595 . >=20 > Only one of: >=20 > devel/arm-none-eabi-gcc > vs. > devel/arm-none-eabi-gcc492 >=20 > can be installed at a time and to > install one required removal/deletion of > the other first (if it already exists). >=20 > Other than the conflict everything looks to > have worked up to trying to actually install. >=20 > I expect aarch64's attempt at devel/aarch64-gcc > to do the same sort of thing. >=20 > aarch64 is still working on: >=20 > devel/powerpc64-gcc > devel/riscv64-gcc > devel/sparc64-gcc > devel/amd64-gcc >=20 > (It has made it to devel/sparc64 , having > installed devel/powerpc64-gcc and > devel/riscv64-gcc . No package failures > but I'm using D10537's patch and I'm > using head -r317015 and other details which > are likely different from what -r439595 was > based on.) [I seem to have forgotten to list devel/mips-gcc and devel/mips64-gcc and so will have to start those builds on aarch64.] The aarch64 attempt at building devel/amd64-gcc also got the "=3Da" problem, for example: = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c:608:2: error: invalid output constraint '=3Da' in asm __cpuid (0x80000002, name, ebx, ecx, edx); ^ = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ ^ This did match the -r439595 report for the combination. But for every non-amd64 host that I tried that used clang to build devel/amd64-gcc the same problem happened. (I did no testing of gcc 4.2.1 or other compilers than system-clang under head -r317015.) Other than the devel/arm-none-eabi-gcc492 conflict with devel/arm-none-eabi-gcc everything else built on aarch64 just fine: =3D=3D=3D>>> The following actions were performed: Installation of devel/powerpc64-binutils = (powerpc64-binutils-2.27_5,1) Installation of devel/powerpc64-gcc (powerpc64-gcc-6.3.0) Installation of devel/riscv64-binutils = (riscv64-binutils-2.27.51.20161101) Installation of devel/riscv64-gcc (riscv64-gcc-6.1.0) Installation of devel/sparc64-binutils = (sparc64-binutils-2.27_5,1) Installation of devel/sparc64-gcc (sparc64-gcc-6.3.0) Installation of devel/amd64-binutils (amd64-binutils-2.27_5,1) where before I'd reported: =3D=3D=3D>>> The following actions were performed: Re-installation of aarch64-none-elf-gcc-6.3.0 Installation of devel/arm-none-eabi-binutils = (arm-none-eabi-binutils-2.27_5,1) Installation of devel/arm-none-eabi-gcc = (arm-none-eabi-gcc-6.3.0) and I'd tested building devel/aarch64-gcc on aarch64 as part of testing the patch in D10537 earlier in the day. Note: This is different than the -r439595 reports for aarch64 hosts: devel/aarch64-gcc: +BROKEN_aarch64=3D configure: error: cannot compute suffix = of object files: cannot compile devel/aarch64-none-elf-gcc: devel/arm-none-eabi-gcc: devel/powerpc64-gcc: devel/riscv64-gcc: devel/sparc64-gcc: +BROKEN_aarch64=3D fails to package (Some of those might be from some prior install that conflicts, like I saw for devel/arm-none-eabi-gcc492? Of course I was also using -r436731 of devel/*binutils (2.27) because of some known 2.28 build failures associated with 2.28. ) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 29 08:19: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 52577D545F8 for ; Sat, 29 Apr 2017 08:19:21 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 15151796 for ; Sat, 29 Apr 2017 08:19:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10814 invoked from network); 29 Apr 2017 08:19:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Apr 2017 08:19:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 29 Apr 2017 04:19:18 -0400 (EDT) Received: (qmail 357 invoked from network); 29 Apr 2017 08:19:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Apr 2017 08:19:18 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D7EC3EC8B18; Sat, 29 Apr 2017 01:19:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: svn commit: r439595 - in head/devel: aarch64-gcc aarch64-none-elf-gcc amd64-gcc arm-none-eabi-gcc arm-none-eabi-gcc492 mips-gcc mips64-gcc powerpc64-gcc riscv64-gcc sparc64-gcc From: Mark Millard In-Reply-To: Date: Sat, 29 Apr 2017 01:19:17 -0700 Cc: Alexander Kabaev Content-Transfer-Encoding: quoted-printable Message-Id: <9436F464-2A4D-42A7-83E1-4425F4F23402@dsl-only.net> References: <8E45FA57-8D2E-4159-8E02-6A5044000CC2@dsl-only.net> <27396BB5-21BC-453A-AD14-E711C15D365F@dsl-only.net> <5EC77319-3775-4333-BD1E-B08359C354E3@dsl-only.net> <1E21DD74-6F0E-4D60-8595-95BFDEC0884B@dsl-only.net> To: svn-ports-head@freebsd.org, Mark Linimon , FreeBSD Toolchain 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, 29 Apr 2017 08:19:21 -0000 On 2017-Apr-28, at 10:59 PM, Mark Millard = wrote: > On 2017-Apr-28, at 8:40 PM, Mark Millard = wrote: >=20 >> On 2017-Apr-28, at 7:15 PM, Mark Millard = wrote: >>=20 >>> On 2017-Apr-28, at 6:10 PM, Mark Millard = wrote: >>>=20 >>>> On 2017-Apr-28, at 5:24 PM, Mark Millard = wrote: >>>>=20 >>>>> On 2017-Apr-28, at 3:27 PM, Mark Millard = wrote: >>>>>=20 >>>>>> Just FYI: >>>>>>=20 >>>>>> https://reviews.freebsd.org/D10537 may help with powerpc64-gcc >>>>>> slave ports (and powerpc64-gcc itself) when they are built on >>>>>> the type of machine that they target. >>>>>>=20 >>>>>> As of devel/*binutils -r436732 and -r432733 (the update >>>>>> to 2.28) many things are broken for linking with debug >>>>>> information that were not before (for example). It turns >>>>>> out to be because of a change in return code for reporting >>>>>> issues for the cases I know about: the new return code >>>>>> stops the build (and the return code is likely appropriate >>>>>> long term as I understand). For example a formerly ignored >>>>>> debug information issue now blocks various builds when a >>>>>> (modern) binutils is involved. >>>>>>=20 >>>>>> [Because of this I've been reverting devel/*binutils >>>>>> to -r436731 each time I update the revision of >>>>>> /usr/ports.] >>>>>>=20 >>>>>> As of ports head -r439263 with reverting >>>>>> devel/*binutils to -r436731 and the patch >>>>>> from D10537 I tested building the following >>>>>> earlier today as part of reviewing D10537: >>>>>>=20 >>>>>> amd64: built amd64-gcc powerpc64-gcc aarch64-gcc >>>>>> powerpc64: built powerpc64-gcc >>>>>> aarch64: built aarch64-gcc >>>>>> (Note: aarch64 is using -mcpu=3Dcortex-a53 explicitly.) >>>>>>=20 >>>>>> Context: head -r317015 in each case. >>>>>> (WITH_LLD_IS_LD=3D was used on aarch64.) >>>>>> (powerpc64 is system-clang/libc++ based, used >>>>>> devel/*binutils) >>>>>>=20 >>>>>> If the information would be useful I could try >>>>>> some other combinations under the patch and >>>>>> the older binutils for comparison. (That does >>>>>> not say when anyone might use the information.) >>>>>>=20 >>>>>> I also have access to armv7. (In this context >>>>>> I normally use -mcpu=3Dcortex-a7 explicitly.) >>>>>> So I could try that type of host as well. >>>>>>=20 >>>>>> I do not have access to mips, mips64, riscv, sparc64 >>>>>> so they could be targets but not hosts in my tests: >>>>>> always cross-builds. >>>>>>=20 >>>>>> I have access to powerpc but currently am not well >>>>>> set up to use it without rebuilding it as gcc 4.2.1 >>>>>> based for buildworld, not just buildkernel. (clang >>>>>> generates bad stack handling for some contexts for >>>>>> 32-bit powerpc.) >>>>>=20 >>>>> I tried building devel/amd64-gcc on a powerpc64 >>>>> head -r317015 system that was built with clang >>>>> and libc++ and has clang as its system compiler. >>>>> /usr/ports as of -r439263 but devel/*binutils as >>>>> of -r436731 (so 2.27 instead of 2.2.8). The result >>>>> was the "=3Da" problem for the clang based build: >>>>>=20 >>>>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:223:3: error: invalid output constraint '=3Da' in asm >>>>> __cpuid (__ext, __eax, __ebx, __ecx, __edx); >>>>> ^ >>>>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' >>>>> : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ >>>>> . . . (other such messages) . . . >>>>> In file included from = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/co= nfig/i386/driver-i386.c:554::225: error: invalid output constraint '=3Da' = in asm >>>>> . . . >>>>> : "=3Da" (eax), "=3Dd" (edx) >>>>> ^ >>>>> . . . >>>>>=20 >>>>> So this system-clang context on powerpc64 is like -r439595 >>>>> reports for building devel/amd64-gcc on aarch64: >>>>>=20 >>>>> +BROKEN_aarch64=3D error: invalid output constraint = '=3Da' in asm >>>>>=20 >>>>> head/devel/amd64-gcc/Makefile only says: >>>>>=20 >>>>> BROKEN_powerpc64=3D Does not build >>>>>=20 >>>>> but it is like on aarch64 --at least when system-clang >>>>> compiler that is in use. >>>>>=20 >>>>> The compiler command lines were: >>>>>=20 >>>>> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/. = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../lib > b >> ac >>>> kt >>>>> race -B/usr/local/bin/ -DLIBICONV_PLUG -o driver-i386.o -MT = driver-i386.o -MMD -MP -MF ./.deps/driver-i386.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c >>>>>=20 >>>>> c++ -std=3Dgnu++98 -fno-PIE -c -O2 -pipe -B/usr/local/bin/ = -DLIBICONV_PLUG -g -fno-strict-aliasing -B/usr/local/bin/ = -DLIBICONV_PLUG -DIN_GCC -fno-strict-aliasing -fno-exceptions = -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing = -Wwrite-strings -Wcast-qual -Wmissing-format-attribute = -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros = -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic-family = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family= = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../inclu= de = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libcp= p/include -I/usr/local/include = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/../libde= cnumber/dpd -I../libdecnumber = -I/usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6. > 3 >> .0 >>>> /g >>>>> cc/../libbacktrace -B/usr/local/bin/ -DLIBICONV_PLUG -o = c-family/cppspec.o -MT c-family/cppspec.o -MMD -MP -MF = c-family/.deps/cppspec.TPo = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/c-family/c= ppspec.c >>>>>=20 >>>>> It will be a fairly long time before the aarch64 >>>>> context gets to this point in a devel/adm64-gcc >>>>> build, although I expect a replication of the >>>>> reported behavior for building devel/amd64-gcc . >>>>=20 >>>> Based on the aarch64 context specified in the >>>> original note (system version, /usr/ports versions, >>>> and the like). . . >>>>=20 >>>> The following built fine: >>>>=20 >>>> =3D=3D=3D>>> The following actions were performed: >>>> Re-installation of aarch64-none-elf-gcc-6.3.0 >>>> Installation of devel/arm-none-eabi-binutils = (arm-none-eabi-binutils-2.27_5,1) >>>> Installation of devel/arm-none-eabi-gcc = (arm-none-eabi-gcc-6.3.0) >>>>=20 >>>> But devel/arm-none-eabi-gcc492 then conflicts with >>>> devel/arm-none-eabi-gcc : >>>>=20 >>>> =3D=3D=3D> Registering installation for = arm-none-eabi-gcc492-4.9.2_2 >>>> Installing arm-none-eabi-gcc492-4.9.2_2... >>>> pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ >>>> *** Error code 70 >>>>=20 >>>> So to test devel/arm-none-eabi-gcc492 fully requires that >>>> any pre-installed devel/arm-none-eabi-gcc first be >>>> deleted/removed. >>>>=20 >>>> There is every indication that absent the conflict >>>> devel/arm-none-eabi-gcc492 would have installed just >>>> fine and it did build to the point of installing. >>>>=20 >>>> So the following did not have package problems: >>>>=20 >>>> devel/aarch64-none-elf-gcc-6.3.0 >>>> devel/arm-none-eabi-gcc >>>>=20 >>>> But that last was given that devel/arm-none-eabi-gcc492 >>>> had not been installed. >>>>=20 >>>>=20 >>>> I still have the following to go on aarch64 (cortex-a53): >>>>=20 >>>> devel/powerpc64-gcc >>>> devel/riscv64-gcc >>>> devel/sparc64-gcc >>>> devel/amd64-gcc >>>>=20 >>>> I also have armv7 (cortex-a7) attempting: >>>>=20 >>>> devel/arm-none-eabi-gcc492 >>>> devel/amd64-gcc >>>=20 >>> The armv7 attempt at devel/amd64-gcc also got >>> the "=3Da" problem, such as: >>>=20 >>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c:608:2: error: invalid output constraint '=3Da' in asm >>> __cpuid (0x80000002, name, ebx, ecx, edx); >>> ^ >>> = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' >>> : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ >>> ^ >>>=20 >>> So this is like what devel/powerpc64-gcc got in a >>> system-clang based context --and armv7 is again >>> based on clang so the message is from clang. (I >>> expect aarch64 to get the same thing once it >>> tries devel/amd64-gcc since -r439595 reports >>> such for aarch64.) >>>=20 >>> Not that this is different from -r439595's >>> report, which said for devel/amd64-gcc: >>>=20 >>> +BROKEN_armv6=3D fails to package >>>=20 >>> Since the compile problem would before any >>> package attempt I've no clue how -r439595 >>> got as far as package if it was using clang >>> to do the build. >>>=20 >>> armv7 still has devel/arm-none-eabi-gcc492 to go. >>>=20 >>> aarch64 is working on: >>>=20 >>> devel/powerpc64-gcc >>> devel/riscv64-gcc >>> devel/sparc64-gcc >>> devel/amd64-gcc >>=20 >> The armv7 attempt at devel/arm-none-eabi-gcc492 also >> got the conflict with devel/arm-none-eabi-gcc : >>=20 >> =3D=3D=3D> Registering installation for = arm-none-eabi-gcc492-4.9.2_2 >> Installing arm-none-eabi-gcc492-4.9.2_2... >> pkg-static: arm-none-eabi-gcc492-4.9.2_2 conflicts with = arm-none-eabi-gcc-6.3.0 (installs files into the same place). = Problematic file: /usr/local/bin/arm-none-eabi-c++ >> *** Error code 70 >>=20 >> Note that this is different than the -r439595 >> report: >>=20 >> +BROKEN_armv6=3D error: no member named 'fancy_abort' in = namespace 'std::__1'; did you mean simply 'fancy_abort'? >>=20 >> I've no clue what caused the "fancy_abort" problem >> reported in -r439595 . >>=20 >> Only one of: >>=20 >> devel/arm-none-eabi-gcc >> vs. >> devel/arm-none-eabi-gcc492 >>=20 >> can be installed at a time and to >> install one required removal/deletion of >> the other first (if it already exists). >>=20 >> Other than the conflict everything looks to >> have worked up to trying to actually install. >>=20 >> I expect aarch64's attempt at devel/aarch64-gcc >> to do the same sort of thing. >>=20 >> aarch64 is still working on: >>=20 >> devel/powerpc64-gcc >> devel/riscv64-gcc >> devel/sparc64-gcc >> devel/amd64-gcc >>=20 >> (It has made it to devel/sparc64 , having >> installed devel/powerpc64-gcc and >> devel/riscv64-gcc . No package failures >> but I'm using D10537's patch and I'm >> using head -r317015 and other details which >> are likely different from what -r439595 was >> based on.) >=20 > [I seem to have forgotten to list devel/mips-gcc > and devel/mips64-gcc and so will have to start > those builds on aarch64.] >=20 > The aarch64 attempt at building devel/amd64-gcc also > got the "=3Da" problem, for example: >=20 > = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/driver-i386.c:608:2: error: invalid output constraint '=3Da' in asm > __cpuid (0x80000002, name, ebx, ecx, edx); > ^ > = /usr/obj/portswork/usr/ports/devel/amd64-gcc/work/gcc-6.3.0/gcc/config/i38= 6/cpuid.h:165:7: note: expanded from macro '__cpuid' > : "=3Da" (a), "=3Db" (b), "=3Dc" (c), "=3Dd" (d) \ > ^ >=20 > This did match the -r439595 report for the combination. >=20 > But for every non-amd64 host that I tried that used > clang to build devel/amd64-gcc the same problem happened. > (I did no testing of gcc 4.2.1 or other compilers than > system-clang under head -r317015.) >=20 > Other than the devel/arm-none-eabi-gcc492 > conflict with devel/arm-none-eabi-gcc everything > else built on aarch64 just fine: >=20 > =3D=3D=3D>>> The following actions were performed: > Installation of devel/powerpc64-binutils = (powerpc64-binutils-2.27_5,1) > Installation of devel/powerpc64-gcc (powerpc64-gcc-6.3.0) > Installation of devel/riscv64-binutils = (riscv64-binutils-2.27.51.20161101) > Installation of devel/riscv64-gcc (riscv64-gcc-6.1.0) > Installation of devel/sparc64-binutils = (sparc64-binutils-2.27_5,1) > Installation of devel/sparc64-gcc (sparc64-gcc-6.3.0) > Installation of devel/amd64-binutils (amd64-binutils-2.27_5,1) >=20 > where before I'd reported: >=20 > =3D=3D=3D>>> The following actions were performed: > Re-installation of aarch64-none-elf-gcc-6.3.0 > Installation of devel/arm-none-eabi-binutils = (arm-none-eabi-binutils-2.27_5,1) > Installation of devel/arm-none-eabi-gcc = (arm-none-eabi-gcc-6.3.0) >=20 > and I'd tested building devel/aarch64-gcc on aarch64 > as part of testing the patch in D10537 earlier in the > day. >=20 > Note: This is different than the -r439595 reports > for aarch64 hosts: >=20 > devel/aarch64-gcc: > +BROKEN_aarch64=3D configure: error: cannot compute suffix = of object files: cannot compile >=20 > devel/aarch64-none-elf-gcc: > devel/arm-none-eabi-gcc: > devel/powerpc64-gcc: > devel/riscv64-gcc: > devel/sparc64-gcc: > +BROKEN_aarch64=3D fails to package >=20 > (Some of those might be from some prior install > that conflicts, like I saw for > devel/arm-none-eabi-gcc492? Of course I was also > using -r436731 of devel/*binutils (2.27) because > of some known 2.28 build failures associated with > 2.28. ) As for aarch64 building/installing devel/mips-gcc and devel/mips64-gcc in my context: =3D=3D=3D>>> The following actions were performed: Installation of devel/mips-binutils (mips-binutils-2.27_5,1) Installation of devel/mips-gcc (mips-gcc-6.3.0) Installation of devel/mips64-binutils (mips64-binutils-2.27_5,1) Installation of devel/mips64-gcc (mips64-gcc-6.3.0) So no problem. This is different from -r439595 reporting for both: +BROKEN_aarch64=3D fails to package That completes a round of testing hosts: aarch64 (using -mcpu=3Dcortex-a53 ) armv6 (on a armv7 using -mcpu=3Dcortex-a7 ) powerpc64 (even this using system-clang) relative to the -r439595 reports but based on using the patch from D10537, using 2.27 of devel/*binutils and the like (-r436731 ), /usr/ports at -r439263 otherwise, all using system-clang to do the builds (head -r317015 ). Hopefully comparison/contrast will provide some useful information. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Apr 29 22:47: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 B9498D56725 for ; Sat, 29 Apr 2017 22:47:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-51.reflexion.net [208.70.210.51]) (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 6A60E1EEA for ; Sat, 29 Apr 2017 22:47:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13865 invoked from network); 29 Apr 2017 22:47:56 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Apr 2017 22:47:56 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 29 Apr 2017 18:47:56 -0400 (EDT) Received: (qmail 22195 invoked from network); 29 Apr 2017 22:47:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Apr 2017 22:47:56 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A03B7EC81E7; Sat, 29 Apr 2017 15:47:55 -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: Re: svn commit: r317169 - head/release/tools Message-Id: Date: Sat, 29 Apr 2017 15:47:55 -0700 To: Glen Barber , svn-src-head@freebsd.org, FreeBSD Toolchain 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, 29 Apr 2017 22:47:58 -0000 > Author: gjb > Date: Wed Apr 19 21:18:06 2017 > New Revision: 317169 > URL:=20 > https://svnweb.freebsd.org/changeset/base/317169 >=20 >=20 > Log: > Trim trailing '/release/..' when setting _OBJDIR so arm64/aarch64 > boot1.efifat is properly located when creating virtual machine = images. > =20 > Sponsored by: The FreeBSD Foundation >=20 > Modified: > head/release/tools/vmimage.subr >=20 > Modified: head/release/tools/vmimage.subr > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/release/tools/vmimage.subr Wed Apr 19 20:45:46 2017 = (r317168) > +++ head/release/tools/vmimage.subr Wed Apr 19 21:18:06 2017 = (r317169) > @@ -15,6 +15,7 @@ write_partition_layout() { > fi > =20 > _OBJDIR=3D"$(make -C ${WORLDDIR} -V .OBJDIR)" > + _OBJDIR=3D"$(realpath ${_OBJDIR})" > if [ -d "${_OBJDIR%%/usr/src}/${TARGET}.${TARGET_ARCH}" ]; then > = BOOTFILES=3D"/${_OBJDIR%%/usr/src}/${TARGET}.${TARGET_ARCH}/usr/src/sys/bo= ot" > else In my experiments with making my own vmimage I had to make another change. Instead of just: _OBJDIR=3D"$(make -C ${WORLDDIR} -V .OBJDIR)" I had to add a use of realpath around ${WORLDDIR} to get the make -V .OBJDIR output to be correct: _OBJDIR=3D"$(make -C $(realpath ${WORLDDIR}) -V .OBJDIR)" The .. use in WORLDDIR blocked the -V .OBJDIR from returning the relevant/correct path. This in turn lead to -p efi:=3D${BOOTFILES}/efi/boot1/boot1.efifat \ reporting the boot1.efifat as not found. With the additional realpath use the relevant/correct path was returned by -V .OBJDIR and boot1.efifat was found. (This is among other more experimental personal-use changes not appropriate to be checked-in. But the additional realpath use seemed to be appropriate svn content.) Other minor notes: BOOTFILES ends up with a leading // in a lot of contexts (including via the else clause assignment not shown). (Not a problem for me.) Use of /usr/src as the source tree is effectively required? (Not a problem for me.) For some reason aarch64 always has NOSWAP=3D1 and no provision for a swap partition. (This is part of why I was experimenting.) While Makefile.vm has "SWAPSIZE?=3D 1G", much like it has "VMSIZE?=3D 20G", SWAPSIZE does not have an equivalent of: scripts/mk-vmimage.sh: VMSIZE=3D"${OPTARG}" and so any SWAPSIZE control is external and implicit. =3D=3D=3D Mark Millard markmi at dsl-only.net