From owner-freebsd-toolchain@freebsd.org Sun Nov 5 00:15:00 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 7CAEBE5B35E for ; Sun, 5 Nov 2017 00:15:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-141.reflexion.net [208.70.210.141]) (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 2A19E64D4A for ; Sun, 5 Nov 2017 00:14:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29739 invoked from network); 5 Nov 2017 00:14:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Nov 2017 00:14:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 04 Nov 2017 20:14:58 -0400 (EDT) Received: (qmail 18160 invoked from network); 5 Nov 2017 00:14:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Nov 2017 00:14:57 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2747CEC7B31; Sat, 4 Nov 2017 17:14:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [toolchain] lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: Date: Sat, 4 Nov 2017 17:14:56 -0700 Cc: =?utf-8?Q?Eddy_Petri=C8=99or?= , freebsd-arm@freebsd.org, freebsd-toolchain@freebsd.org, Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <505436FF-E15C-42DE-8855-47FB5A99E64B@dsl-only.net> References: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> To: Gerald Pfeifer X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 00:15:00 -0000 On 2017-Nov-4, at 3:57 PM, Gerald Pfeifer wrote: > On Sun, 29 Oct 2017, Eddy Petri=C8=99or wrote: >> Yep --and it is even more complicated: gcc vs. clang are sometimes=20 >> different for the target listed. . . >>=20 >> For example -m32 for amd64 changes the clang result: >>=20 >> # clang -dumpmachine >> x86_64-unknown-freebsd12.0 >>=20 >> .. >>=20 >> # gcc7 -dumpmachine >> x86_64-portbld-freebsd12.0 >=20 > That's not actually related to GCC, but the lang/gcc* ports using > the FreeBSD Ports Collection's default that explicitly set >=20 > CONFIGURE_TARGET?=3D ${ARCH}-portbld-${OPSYS:tl}${OSREL} >=20 > By default GCC would use the same as clang. Interesting. Good to know. Thanks. We still end up with depending on --dumpmachine giving non-uniform results across typical compilers in a standard FreeBSD environment. It looks like depending on -dumpmachine should be avoided for any more than a local workaround. (Some Linux distributions might also vary such definitions to be non-default as well for all I know.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Nov 5 00:19: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 0A253E5B5EC; Sun, 5 Nov 2017 00:19:20 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DCC864F4B; Sun, 5 Nov 2017 00:19:19 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id z3so7831627wme.5; Sat, 04 Nov 2017 17:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JeaazDEINv/lxmC+4MuXS7uSYd6jQpHTuPotz05zJoA=; b=PAUbWor+gzAAdbhsUfxDFOZL4NDwwKOxFGJ6CN7jjR4UVd2YHA1Q+mB//YKgy+PS+F SQvYDjY8p4fBZUbwWdrwmw7r2LyW22u1ayYAHVvh1o5YmOJ6W7OJg58TVV6QdpgSZgmT l51NLm3i+wsZrgb0gGDkxhy2KAOGIsefz4R+IwZ7SQfm/GAhKZpfLlpH1eIbT+J5wpN2 0MR+X6oWRRIqRMql0xGPpo/qMix945TgSy76S1KCcoDhWyKKj9TFmXcDqhJwYOBYLII2 WydE7VlZEMzvDSX8Je0us4zybIoGDMnCL9cYd5ugdm6AitbovBRbywoMUow/TqJ9uYQx iGgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JeaazDEINv/lxmC+4MuXS7uSYd6jQpHTuPotz05zJoA=; b=FRxfo4Aeb7JATOfBNoM3DyVLCfS86nLbDbwMSZkR51k5DF/VXs9plRSyrxPcTcO9PW eQdWrZlNdfaGVgyQjTbofmiYM5XWevUzrDLxDtLkpXuhUnTIPl7UAWd3rEClKJQEg5FW RKgjW4VtXRDZHxVhbxztZiwUxxScLbzUXte1gycOP2WtWxe95NYTNSIi/K1kQsUebNPq WrVhU0pu0hXK7iSHkgGXuhMSFcJncpBNNH1Yhu487vRdx2aY68hfMgWKR1gQu53jzv7E kY+21bov7ziFeaaBlBylzVF2YKBWAB33LsCDOy7wquDBGRahcJVVagLgx8ezOJCX1Get Avog== X-Gm-Message-State: AJaThX4uV5h/2lhgNGgfEwjua7dXuFPDVDYoWPXrj8s34WQnrYf6jd4v npk96p8XwyPMZ1WAUbRPY3TmtRTp14RUCqZkfVE= X-Google-Smtp-Source: ABhQp+RrmvnWws2hu/S7kA8IK/UgqUg2w+rRlGThl2BfLpQSDqPTUD3g1rqq3xxqX/fyrVq4kdgUrHF7OpWjWKCI10c= X-Received: by 10.28.111.203 with SMTP id c72mr2441337wmi.42.1509841156823; Sat, 04 Nov 2017 17:19:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.184.87 with HTTP; Sat, 4 Nov 2017 17:19:15 -0700 (PDT) Received: by 10.223.184.87 with HTTP; Sat, 4 Nov 2017 17:19:15 -0700 (PDT) In-Reply-To: References: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Sun, 5 Nov 2017 02:19:15 +0200 Message-ID: Subject: Re: [toolchain] lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? To: Gerald Pfeifer Cc: Mark Millard , freebsd-arm@freebsd.org, freebsd-toolchain@freebsd.org, Dimitry Andric Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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, 05 Nov 2017 00:19:20 -0000 Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer" a scris: On Sun, 29 Oct 2017, Eddy Petri=C8=99or wrote: > Yep --and it is even more complicated: gcc vs. clang are sometimes > different for the target listed. . . > > For example -m32 for amd64 changes the clang result: > > # clang -dumpmachine > x86_64-unknown-freebsd12.0 > > .. > > # gcc7 -dumpmachine > x86_64-portbld-freebsd12.0 That's not actually related to GCC, but the lang/gcc* ports using the FreeBSD Ports Collection's default that explicitly set Yes, I know. That's why I said the vendor part must be forced to "unknown". CONFIGURE_TARGET?=3D ${ARCH}-portbld-${OPSYS:tl}${OSREL} By default GCC would use the same as clang. Sure, but that doesn't mean the vendor part of the triple in the default compiler is guaranteed to be 'unknown'. Eddy Petri=C8=99or From owner-freebsd-toolchain@freebsd.org Sun Nov 5 01:02: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 3E17BE5C4F7 for ; Sun, 5 Nov 2017 01:02:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-164.reflexion.net [208.70.210.164]) (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 DFF6F66489 for ; Sun, 5 Nov 2017 01:02:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32227 invoked from network); 5 Nov 2017 01:02:18 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 5 Nov 2017 01:02:18 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 04 Nov 2017 21:02:18 -0400 (EDT) Received: (qmail 4639 invoked from network); 5 Nov 2017 01:02:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Nov 2017 01:02:18 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 60655EC7B31; Sat, 4 Nov 2017 18:02:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [toolchain] lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: Date: Sat, 4 Nov 2017 18:02:16 -0700 Cc: Gerald Pfeifer , freebsd-arm@freebsd.org, freebsd-toolchain@freebsd.org, Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <12E66105-6E1D-4941-B4C4-3BBAC0F3B330@dsl-only.net> References: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> To: =?utf-8?Q?Eddy_Petri=C8=99or?= X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 01:02:20 -0000 On 2017-Nov-4, at 5:19 PM, Eddy Petri=C8=99or wrote: > Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer" a = scris: > On Sun, 29 Oct 2017, Eddy Petri=C8=99or wrote: > > Yep --and it is even more complicated: gcc vs. clang are sometimes > > different for the target listed. . . > > > > For example -m32 for amd64 changes the clang result: > > > > # clang -dumpmachine > > x86_64-unknown-freebsd12.0 > > > > .. > > > > # gcc7 -dumpmachine > > x86_64-portbld-freebsd12.0 >=20 > That's not actually related to GCC, but the lang/gcc* ports using > the FreeBSD Ports Collection's default that explicitly set >=20 > Yes, I know. That's why I said the vendor part must be forced to = "unknown". >=20 >=20 > CONFIGURE_TARGET?=3D ${ARCH}-portbld-${OPSYS:tl}${OSREL} >=20 > By default GCC would use the same as clang. >=20 > Sure, but that doesn't mean the vendor part of the triple in the = default compiler is guaranteed to be 'unknown'. The "unknown" vs. "portbld" has a specific meaning for a FreeBSD context: unknown: it is a devel/* port portbld: it is a lang/* port This keeps the likes of devel/powerpc64-gcc and lang/gcc6 from having conflicting files on a powerpc64 FreeBSD machine, even when they are at the same (full) version. The variation that I intended to write about was the x86_64 vs. i386 variation when -m32 is in use. That is a separate issue from unknown vs. portbld . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Nov 5 01:22:10 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 2E99CE5CE3E for ; Sun, 5 Nov 2017 01:22:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-113.reflexion.net [208.70.210.113]) (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 D046D66C18 for ; Sun, 5 Nov 2017 01:22:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32227 invoked from network); 5 Nov 2017 01:22:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Nov 2017 01:22:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 04 Nov 2017 21:22:03 -0400 (EDT) Received: (qmail 5422 invoked from network); 5 Nov 2017 01:22:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 5 Nov 2017 01:22:03 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A8EBCEC7B31; Sat, 4 Nov 2017 18:22:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [toolchain] lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? From: Mark Millard In-Reply-To: <12E66105-6E1D-4941-B4C4-3BBAC0F3B330@dsl-only.net> Date: Sat, 4 Nov 2017 18:22:02 -0700 Cc: freebsd-arm , Dimitry Andric , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> <12E66105-6E1D-4941-B4C4-3BBAC0F3B330@dsl-only.net> To: =?utf-8?Q?Eddy_Petri=C8=99or?= X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 01:22:10 -0000 On 2017-Nov-4, at 6:02 PM, Mark Millard wrote: > On 2017-Nov-4, at 5:19 PM, Eddy Petri=C8=99or wrote: >=20 >> Pe 5 nov. 2017 12:57 AM, "Gerald Pfeifer" a = scris: >> On Sun, 29 Oct 2017, Eddy Petri=C8=99or wrote: >>> Yep --and it is even more complicated: gcc vs. clang are sometimes >>> different for the target listed. . . >>>=20 >>> For example -m32 for amd64 changes the clang result: >>>=20 >>> # clang -dumpmachine >>> x86_64-unknown-freebsd12.0 >>>=20 >>> .. >>>=20 >>> # gcc7 -dumpmachine >>> x86_64-portbld-freebsd12.0 >>=20 >> That's not actually related to GCC, but the lang/gcc* ports using >> the FreeBSD Ports Collection's default that explicitly set >>=20 >> Yes, I know. That's why I said the vendor part must be forced to = "unknown". >>=20 >>=20 >> CONFIGURE_TARGET?=3D ${ARCH}-portbld-${OPSYS:tl}${OSREL} >>=20 >> By default GCC would use the same as clang. >>=20 >> Sure, but that doesn't mean the vendor part of the triple in the = default compiler is guaranteed to be 'unknown'. >=20 > The "unknown" vs. "portbld" has a specific meaning > for a FreeBSD context: >=20 > unknown: it is a devel/* port > portbld: it is a lang/* port >=20 > This keeps the likes of devel/powerpc64-gcc > and lang/gcc6 from having conflicting files > on a powerpc64 FreeBSD machine, even when > they are at the same (full) version. >=20 > The variation that I intended to write about > was the x86_64 vs. i386 variation when -m32 > is in use. That is a separate issue from > unknown vs. portbld . I forgot to mention that I also intended to write about the -gnueabihf suffix vs. not for armv7 between various normal FreeBSD compilers (system and ports compilers). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Nov 5 19:52: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 BF7D2E4FA2E for ; Sun, 5 Nov 2017 19:52: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 A68B267ECA for ; Sun, 5 Nov 2017 19:52: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 vA5JqKVh058403 for ; Sun, 5 Nov 2017 19:52:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223333] science/simlib: crashes nm(1) during build Date: Sun, 05 Nov 2017 19:52:20 +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: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@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: 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, 05 Nov 2017 19:52:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223333 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org --- Comment #2 from Ed Maste --- (In reply to Jan Beich from comment #1) Do you have the mangled symbol handy? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Nov 5 20:08:11 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59E74E50168 for ; Sun, 5 Nov 2017 20:08:11 +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 487AC68B00 for ; Sun, 5 Nov 2017 20:08:11 +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 vA5K8Bpi096051 for ; Sun, 5 Nov 2017 20:08:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223333] science/simlib: crashes nm(1) during build Date: Sun, 05 Nov 2017 20:08:11 +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: regression 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: 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, 05 Nov 2017 20:08:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223333 --- Comment #3 from Jan Beich --- $ echo _ZZN7simlib318SIMLIB_create_nameEPKczE1s | /usr/bin/c++filt --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Nov 7 18:18:28 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 8E74FE60BEE; Tue, 7 Nov 2017 18:18:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64E137D49B; Tue, 7 Nov 2017 18:18:28 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id AC012EEE; Tue, 7 Nov 2017 18:18:27 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 8393311DCB; Tue, 7 Nov 2017 18:18:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id t0S0mqXuwJEE; Tue, 7 Nov 2017 18:18:24 +0000 (UTC) To: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 1A01A11DC6 From: Bryan Drewery Subject: native-xtools gcc archs broken Organization: FreeBSD Message-ID: <7bc32cab-24e9-1a05-34e2-3f006918e4ab@FreeBSD.org> Date: Tue, 7 Nov 2017 10:18:04 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VNBeOdm9D3fVCkgTGEt5ud76BNvEgvjrJ" 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, 07 Nov 2017 18:18:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VNBeOdm9D3fVCkgTGEt5ud76BNvEgvjrJ Content-Type: multipart/mixed; boundary="D0nTNusjLtahxswI3x0303oFOBXHxvc1P"; protected-headers="v1" From: Bryan Drewery To: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org Message-ID: <7bc32cab-24e9-1a05-34e2-3f006918e4ab@FreeBSD.org> Subject: native-xtools gcc archs broken --D0nTNusjLtahxswI3x0303oFOBXHxvc1P Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable My recent native-xtools rewrite works fine for clang archs but not GCC archs. I am working on a fix. --=20 Regards, Bryan Drewery --D0nTNusjLtahxswI3x0303oFOBXHxvc1P-- --VNBeOdm9D3fVCkgTGEt5ud76BNvEgvjrJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEE+Rc8ssOq6npcih8JNddxu25Gl88FAloB+N4ACgkQNddxu25G l880uggAyAdd8revoFY8JwXarD5PsuqUbhhlwUSNzGnhuAjIDo6+vllWXoShSu5j rR+Eoqh2laP08Uf4rdBaR9285DjCbeVlKch9Ybib92gXFtdHJII+f1jq6Tg1owLw 3tzX5R65Zy/6iF4hb3hEJKLF/oBElGKZT1T1uKPNdWAH1mo+0AZYxMfGvJHDqAAa UMp62bH+dDSxq2tlNiQqNO6hfW0Q/DBbUC8t4dRYEJHw43y89nxcNW/15h33nFs1 iQkglfOKK/Ag/XJSjxs0D1Tb0Qs3yP9NuUzd3BhGat2mt8cCyTD5Aov05tRlxCP2 GMaqs1PJkz29rlxH9gqtyqIu5fBLYw== =bTXI -----END PGP SIGNATURE----- --VNBeOdm9D3fVCkgTGEt5ud76BNvEgvjrJ-- From owner-freebsd-toolchain@freebsd.org Wed Nov 8 07:24:57 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 3787FE701A5 for ; Wed, 8 Nov 2017 07:24:57 +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 249F56E714 for ; Wed, 8 Nov 2017 07:24:57 +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 vA87OuK1003532 for ; Wed, 8 Nov 2017 07:24:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages) Date: Wed, 08 Nov 2017 07:24:57 +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: patch 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: rust@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: 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: Wed, 08 Nov 2017 07:24:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223415 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-toolchain@FreeBSD.o | |rg --- Comment #4 from Jan Beich --- Can toolchain@ clarify plans regarding i386 support in future? Is FreeBSD g= oing to be stuck targeting i486 until the architecture is dead? How much effort = port maintainers are supposed to exert for i486 if upstream projects couldn't ca= re less? It's not like FreeBSD to care about ancient hardware (unlike NetBSD). --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Nov 8 18:32:42 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 89355E599A4 for ; Wed, 8 Nov 2017 18:32:42 +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 77600635F8 for ; Wed, 8 Nov 2017 18:32:42 +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 vA8IWf6Z040441 for ; Wed, 8 Nov 2017 18:32:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223415] lang/rust: don't require SSE2 on i386 (at least for binary packages) Date: Wed, 08 Nov 2017 18:32:42 +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: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rust@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: 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: Wed, 08 Nov 2017 18:32:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223415 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org --- Comment #5 from Dimitry Andric --- (In reply to Jan Beich from comment #4) > Can toolchain@ clarify plans regarding i386 support in future? Is FreeBSD > going to be stuck targeting i486 until the architecture is dead? I think the architecture itself will live on for quite some time, whether we like it or not. In my opinion we should start requiring at least i686 or higher (or maybe even pentium4). IIRC there have been plans to start an arch separate from i386, specifically for updating to 64-bit time_t, that could maybe also be used for such an update. :) On the other hand, in Linux land there are already distros dropping i386 completely, e.g: https://www.archlinux.org/news/the-end-of-i686-support/ > How much > effort port maintainers are supposed to exert for i486 if upstream projec= ts > couldn't care less? It's not like FreeBSD to care about ancient hardware > (unlike NetBSD). At some point, I guess we must simply stop supporting some ports for such targets. I can't be too long until firefox and chromium are simply too lar= ge to run in a 32-bit address space... --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Nov 9 05:46:24 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 C3A49E6B850 for ; Thu, 9 Nov 2017 05:46:24 +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 B04CB78C12 for ; Thu, 9 Nov 2017 05:46:24 +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 vA95kOTe033946 for ; Thu, 9 Nov 2017 05:46:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Thu, 09 Nov 2017 05:46:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: 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: 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: Thu, 09 Nov 2017 05:46:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 Mark Linimon 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 Thu Nov 9 08:29:36 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2DBEE6EBE1 for ; Thu, 9 Nov 2017 08:29:36 +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 C44427D3ED for ; Thu, 9 Nov 2017 08:29:36 +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 vA98Tadp087132 for ; Thu, 9 Nov 2017 08:29:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Thu, 09 Nov 2017 08:29:36 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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: Thu, 09 Nov 2017 08:29:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 Mark Millard changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markmi@dsl-only.net --- Comment #1 from Mark Millard --- (In reply to sid from comment #0) I expect that there is a misinterpretation of the https://wiki.freebsd.org/ExternalToolchain wording. (Easily done.) I think that https://wiki.freebsd.org/ExternalToolchain does not well indicate what context it material applies in vs. what context is does not: XCC, XCXX, XCPP, XAS, etc. do not replace all uses of CC, CPP, AS, etc. in all contexts. The description: The XCC approach works with top level build targets (buildworld, buildkerne= l, etc) and overrides common make variables such as CC, CXX, and AS during the cross building portions of the build with values specified by the XCC, XCPP, XAS, etc variables. (end description) sounds like all uses of CC, CXX, AS, and the like are replaced --but that is wrong and would not work for cross-builds. For example, for amd64 -> aarch64 (cortex-A53) cross builds I've used one compiler as the "for host" CC/CXX/CPP and another compiler and its tool chain as the "cross compiler to target" XCC/XCPP/. . . for a cross build context. The cross-compiler tools can not be used for everything because some host software is also built for later use in the overall buildworld that is happening on the host. Some recursive makes replace uses of CC/CXX/CPP and the like with uses of XCC/XCXX/XCPP (for example). But other make activity uses the original definitions above (or the defaults for what is not specified). I've even done examples of a gcc host compiler (and its toolchain) and a separate gcc cross compiler (and its tool chain), avoiding the system compiler for both aspects. That is a type of example where things have to start with CC/CXX/CPP/. . . vs. XCC/XCXX/XCPP/. . . being distinct and the initial CC/CXX/CPP/. . . do have to be used but are not the default (system compiler tied). [devel/*-xtolchain-gcc's are not setup for this fully automatically: they are only the cross-compiler/toolchain part of it.] I'll supply one example for a cross-build that has both CC/CXX/CPP and XCC/XCXX/XCPP/XAS/. . . assignments and needs the distinctions: (The example is for 12.0 but I've done such 11.x and for 10.x in the past. This does use the system compiler/toolchain as the host-targetting compiler/toolchain.) # more ~/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++ XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # From based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif (In some respects the above is explicit about some things that each devel/*-xtoolchain-gcc sets up to do automatically.) So ultimately I think the specifics of any example of a possible bad substitution need to be reported, including the inputs (such as the above), the actual invocation of make, and the bad commands that resulted during a build. With that much context things can be checked and which parts are messed up identified. The submittal is far to generic to identify anything specific that might be wrong. I'll note that I use this stuff extensively for amd64, powerpc64, powerpc, aarc64, and armv7 and cross building amd64 -> (each of the other 4). It seems to work correctly for me and last I tried it devel/*-xtoolchain-gcc based builds were working (and they use this stuff too, but presume the system-compiler for the host targeting part of buildworld). I started doing such things before the devel/*-xtoolchain-gcc's were put in place. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Nov 9 09:28:23 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32C7EE7010E for ; Thu, 9 Nov 2017 09:28:23 +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 1FF337F026 for ; Thu, 9 Nov 2017 09:28:23 +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 vA99SMIW065187 for ; Thu, 9 Nov 2017 09:28:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Thu, 09 Nov 2017 09:28:23 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 09:28:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #2 from Mark Millard --- (In reply to sid from comment #0) I'll also mention that there is a port devel/xtoolchain-llvm50 that installs files to help configure for using llvm50 as a cross-compiler. For example: # more /usr/local/share/toolchains/llvm50.mk XCC=3D/usr/local/bin/clang50 XCXX=3D/usr/local/bin/clang++50 XCPP=3D/usr/local/bin/clang-cpp50 XLD=3D/usr/local/llvm50/bin/ld.lld CROSS_BINUTILS_PREFIX=3D/var/empty X_COMPILER_TYPE=3Dclang An example for a gcc compiler is: # more /usr/local/share/toolchains/aarch64-gcc.mk XCC=3D/usr/local/bin/aarch64-unknown-freebsd12.0-gcc XCXX=3D/usr/local/bin/aarch64-unknown-freebsd12.0-g++ XCPP=3D/usr/local/bin/aarch64-unknown-freebsd12.0-cpp CROSS_BINUTILS_PREFIX=3D/usr/local/aarch64-freebsd/bin/ X_COMPILER_TYPE=3Dgcc It would take also assigning CC/CXX/CPP/. . . in order to also use llvm50 materials as the host compiler/toolchain as well during cross-builds. (Note that the limiting condition of a cross-build is a form of native build, where the target happens to match the host type. But technically the CC/CXX/CPP/. . . could be assigned but the XCC/XCXX/XCPP/. . . left unassigned for "self hosted" that avoids the system compiler.) One does have to consider what to do with (showing WITHOUT_ use): WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D WITH_SYSTEM_COMPILER=3D would be directly indicating to use the system compiler when a cross compiler does not seem to need to be built. WITH_CROSS_COMPILE=3D vs. WITHOUT_CROSS_COMPILER=3D is less obvious and I analyzed source code to see which way had the properties that I was after in each case. In my earlier example it was using WITHOUT_ for both and I explicitly set lots of things. This makes the case structurally more similar to the case of avoiding the system compiler (and potential cross compiler variant): in part it is just replacing some paths. It is not obvious what your host-native vs. cross-build-target intents are for use of: /usr/local/bin/llvm-as50 /usr/local/bin/llvm-ar50 /usr/local/bin/lld-link50 /usr/local/bin/llvm-nm50 /usr/local/bin/llvm-objdump50 /usr/local/bin/llvm-ranlib50 /usr/local/bin/llvm-strings50 (I've had examples of the host-native vs. cross-build-toolchain using different tools.) You may have to specify more of your intent for such things in order to find out what is needed to configure things. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Nov 9 19:20:13 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71EE1E593B6 for ; Thu, 9 Nov 2017 19:20:13 +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 5F79574226 for ; Thu, 9 Nov 2017 19:20:13 +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 vA9JKC2a056679 for ; Thu, 9 Nov 2017 19:20:13 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Thu, 09 Nov 2017 19:20:13 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com 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: Thu, 09 Nov 2017 19:20:13 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #3 from sid@bsdmail.com --- (In reply to Mark Millard from comment #2) You're saying the X prefix doesn't replace buildworld compilers and utils in make.conf settings, it supplements them. If this is the case, perhaps this = is an incorrect bug report. My intent was to replace binutils with either elfutils or llvm's utils. It = was in part for purposes of not having to build/install utils and compilers twi= ce (from the base system, then again from ports), and for modularity and efficiency of utils and compilers. As far as I'm aware, all of binutil's replacements are not completed. Down the road it will be better for testing= , if there is a false sense that the package/ports compiler and utils are used, = when base components are used. llvm40 and llvm50 work much the same. I used llvm50, because I thought perh= aps it's binutils' replacements were more developed. Here's a sample of my src.conf to use clang/llvm from packages. #WITHOUT_TOOLCHAIN=3Dyes #binutils is needed WITH_BINUTILS=3Dyes WITH_BINUTILS_BOOTSTRAP=3Dyes WITHOUT_CLANG=3Dyes WITHOUT_CLANG_BOOTSTRAP=3Dyes WITHOUT_CPP=3Dyes # uncertain about WITHOUT_CXX=3Dyes # needed for devd, gperf and c++ libraries # will use llv= m40/50 WITH_LLVM_LIBUNWIND=3Dyes WITH_LLD_BOOTSTRAP=3Dyes WITH_LLD_IS_LD=3Dyes WITH_LLVM_LIBUNWIND=3Dyes WITHOUT_CROSS_COMPILER=3Dyes WITHOUT_GCC=3Dyes WITHOUT_GCC_BOOTSTRAP=3Dyes WITHOUT_GDB=3Dyes WITHOUT_GPL_DTC=3Dyes WITHOUT_GNU=3Dyes WITHOUT_GNUCXX=3Dyes WITHOUT_GNU_SUPPORT=3Dyes WITH_LLVM_LIBUNWIND=3Dyes With your information, I will adjust my src.conf and make.conf and see if t= hat works for the linker and utils. Thank you. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Nov 9 19:25: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 BA6E9E59641 for ; Thu, 9 Nov 2017 19:25: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 A8960746B5 for ; Thu, 9 Nov 2017 19:25: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 vA9JPx6P072392 for ; Thu, 9 Nov 2017 19:25:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Thu, 09 Nov 2017 19:25: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: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:25:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #4 from Mark Millard --- (In reply to sid from comment #3) What is the host environment? amd64? What is the target environment? Also amd64? (I'll be leaving for a meeting and so will not reply soon even if you do.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Nov 9 19:45:46 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69807E59FF5 for ; Thu, 9 Nov 2017 19:45:46 +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 5778575A31 for ; Thu, 9 Nov 2017 19:45:46 +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 vA9JjkH7022144 for ; Thu, 9 Nov 2017 19:45:46 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Thu, 09 Nov 2017 19:45:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com 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: Thu, 09 Nov 2017 19:45:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #5 from sid@bsdmail.com --- (In reply to Mark Millard from comment #4) Target and host environment are both amd64. Thanks for your help. Not necessarily one person has to respond, anyone can respond. I can also keep tinkering with it. It seems that the X prefix should be used exclusively for base system (and kernel), because most ports build with AS, AR, LD, NM, OBJECTDUMP, RANLIB, = and STRINGS set to llvm from ports. AS=3D /usr/local/bin/llvm-as50 AR=3D /usr/local/bin/llvm-ar50 LD=3D /usr/local/bin/lld-link50 # /usr/local/llvm50/bin/ld.lld NM=3D /usr/local/bin/llvm-nm50 OBJECTDUMP=3D/usr/local/bin/llvm-objdump50 RANLIB=3D /usr/local/bin/llvm-ranlib50 STRINGS=3D /usr/local/bin/llvm-strings50 .... XLD=3D /usr/local/llvm50/bin/ld.lld I will switch over to llvm40 than llvm50, because it is more widely used. B= oth have behaved similarly with these settings. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Nov 9 23:45: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 6C934E5F8AC for ; Thu, 9 Nov 2017 23:45:54 +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 59BFD7DF0C for ; Thu, 9 Nov 2017 23:45:54 +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 vA9NjsC7051804 for ; Thu, 9 Nov 2017 23:45:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Thu, 09 Nov 2017 23:45:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 23:45:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #6 from Mark Millard --- (In reply to sid from comment #5) So, for whatever reason, you want to: buildworld buildkernel in a way that does not build a system compiler or toolchain in the process, neither for internal use of the stages of the build, nor for what would be in the system after installworld. Also you do not want to use any pre-existing system compilers or system tool chain to do this activity but instead use a devel/llvm* . Sound right? (The ports conventions do not really apply to buildworld, although there likely is some overlap.) I used to do this sort of thing for powerpc64 (self hosted), although before devel/llvm*'s time. As I remember I had it build system-clang but not use system-clang. (At the time clang was broken in big ways for powerpc64 so the compiler was basically unusable.) I had it build various things just to prove that the builds could complete, even if they were otherwise unused. As I remember I had to do things to force the system include files and libraries to be used for what I used as the substitute for the "host system compiler/toolchain". The files from the compiler's own environment were not appropriate/sufficient. In more modern terms this would have been using lang/gcc7 and its tool chain as the "host system compiler/toolchain" and devel/powerpc64-gcc and its tool chain as the "cross compiler/toolchain", both targeting powerpc64 (on a powerpc64 context). (Originally it was gcc49 instead of gcc7.) May be the below will help, even though it is not exactly what you are after. Not adjusting the material for devel/llvm40 or devel/llvm50 but modernizing the content some and making it reference amd64 and be appropriate for adm64 (and its set up for 12.0): (preumes lang/gcc7 and devel/adm64-xtoolchain-gcc are installed, dependencies included; still shows building clang materials; I've not tested the below) # more /root/src.configs/src.conf.powerpc64-xtoolchain-gcc.powerpc64-host TO_TYPE=3Damd64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3D${TO_TYPE} TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC TARGET=3Damd64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITH_LLD=3D WITH_LLDB=3D # WITH_BOOT=3D WITH_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D # WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gcc XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g++ XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-cpp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # For FROM (host) stages . . . # From gccXY (such as gcc7 but not xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc7 -L/usr/lib CXX=3Denv C_INCLUDE_PATH=3D/usr/include CPLUS_INCLUDE_PATH=3D/usr/include/c= ++/v1 /usr/local/bin/g++7 -std=3Dc++11 -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp7 .export CC .export CXX .export CPP AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/as AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ar LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ld NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/nm OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/objcopy OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/objdump RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bi= n/ranlib SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/= size #NO-SUCH: STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/strings STRINGS=3D/usr/local/bin/strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif If the X's would be the same as the non-X 's then the X variants should not need definitions for amd64 -> amd64 (as I remember): they are only needed when the content is distinct. I do not remember the details but if I remember right at the time trying to turn off both clang and gcc fully in buildworld was odd in some way and I avoided doing so. It may be that one of them always built anyway and I choose to build clang. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Nov 10 03:15:49 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F2F7E63B84 for ; Fri, 10 Nov 2017 03:15:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-103.reflexion.net [208.70.210.103]) (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 2CF69637D5 for ; Fri, 10 Nov 2017 03:15:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2558 invoked from network); 10 Nov 2017 03:09:02 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 10 Nov 2017 03:09:02 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Thu, 09 Nov 2017 22:09:02 -0500 (EST) Received: (qmail 12910 invoked from network); 10 Nov 2017 03:09:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Nov 2017 03:09:02 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 8D737EC9169; Thu, 9 Nov 2017 19:09:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [Bug 223383] pathconf querying for posix_falloc not supported on freebsd [devel/llvm*'s lld's are also broken by this for zfs and need updating] From: Mark Millard In-Reply-To: Date: Thu, 9 Nov 2017 19:09:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7A1EEAA2-C160-492E-B1DA-24E7D73268BB@dsl-only.net> References: To: FreeBSD Toolchain , FreeBSD Current , FreeBSD Ports , bugzilla-noreply@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 03:15:49 -0000 [ devel/llvm* also have the issue in their lld 's.] On 2017-Nov-7, at 4:43 PM, bugzilla-noreply at freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223383 >=20 > --- Comment #7 from commit-hook@freebsd.org --- > A commit references this bug: >=20 > Author: emaste > Date: Wed Nov 8 00:39:04 UTC 2017 > New revision: 325523 > URL: https://svnweb.freebsd.org/changeset/base/325523 >=20 > Log: > MFC r325420: lld: accept EINVAL to indicate posix_fallocate is = unsupported >=20 > As of r325320 posix_fallocate on a ZFS filesystem returns EINVAL to > indicate that the operation is not supported. (I think this is a = strange > choice of errno on the part of POSIX.) >=20 > PR: 223383, 223440 > Reported by: Mark Millard > Sponsored by: The FreeBSD Foundation >=20 > Changes: > _U stable/11/ > stable/11/contrib/llvm/lib/Support/Unix/Path.inc >=20 > --=20 > You are receiving this mail because: > You are on the CC list for the bug. [Context a zfs file system.] =46rom /usr/src/UPDATING: 20171106: The naive and non-compliant support of posix_fallocate(2) in ZFS has been removed as of r325320. The system call now returns = EINVAL when used on a ZFS file. Although the new behavior complies = with the standard, some consumers are not prepared to cope with it. One known victim is lld prior to r325420. The issue is not limited to the system clang's associated lld.=20 Here is an attempt to use clang++50, implicitly using its associated lld: # clang++50 -v exception_test.cc clang version 5.0.0 (tags/RELEASE_500/final) Target: x86_64-portbld-freebsd12.0 Thread model: posix InstalledDir: /usr/local/llvm50/bin "/usr/local/llvm50/bin/clang-5.0" -cc1 -triple = x86_64-portbld-freebsd12.0 -emit-obj -mrelax-all -disable-free = -main-file-name exception_test.cc -mrelocation-model static = -mthread-model posix -mdisable-fp-elim -masm-verbose = -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v = -dwarf-column-info -debugger-tuning=3Dgdb -resource-dir = /usr/local/llvm50/lib/clang/5.0.0 -internal-isystem /usr/include/c++/v1 = -fdeprecated-macro -fdebug-compilation-dir /root/c_tests -ferror-limit = 19 -fmessage-length 200 -fobjc-runtime=3Dgnustep -fcxx-exceptions = -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o = /tmp/exception_test-baadc9.o -x c++ exception_test.cc clang -cc1 version 5.0.0 based upon LLVM 5.0.0 default target = x86_64-portbld-freebsd12.0 #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/local/llvm50/lib/clang/5.0.0/include /usr/include End of search list. "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker = /libexec/ld-elf.so.1 --hash-style=3Dboth --enable-new-dtags -o a.out = /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib = /tmp/exception_test-baadc9.o -lc++ -lm -lgcc --as-needed -lgcc_s = --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed = /usr/lib/crtend.o /usr/lib/crtn.o /usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid = argument clang-5.0: error: linker command failed with exit code 1 (use -v to see = invocation) https://svnweb.freebsd.org/ports/head/devel/?dir_pagestart=3D1000 does not yet suggest updates to devel/llvm* 's for the issue. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Nov 10 03:19:19 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 7F329E63BF2 for ; Fri, 10 Nov 2017 03:19:19 +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 5487C6384E for ; Fri, 10 Nov 2017 03:19:19 +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 vAA3JJox045688 for ; Fri, 10 Nov 2017 03:19:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Fri, 10 Nov 2017 03:19:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 03:19:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #7 from Mark Millard --- (In reply to sid from comment #0) I used -v to check include paths searched for devel/llvm50 : #include <...> search starts here: /usr/include/c++/v1 /usr/local/llvm50/lib/clang/5.0.0/include /usr/include As I would expect for devel/* it looks like teh devel/llvm* 's were adjusted to use the system include files by default. (If there was a lang/llvm50 then it likely would not have such an adjustment, just like lang/gcc7 does not look there by default.) So it appears that the following paragraph does not apply to your context: As I remember I had to do things to force the system include files and libraries to be used for what I used as the substitute for the "host system compiler/toolchain". The files from the compiler's own environment were not appropriate/sufficient. I will note that currently lld from devel/llvm* 's are broken on zfs from the fallocate change (ZFS does not actually support it but lld tries to use it without detecting the problem). The devel/llvm* 's need to be updated so that they build usable lld 's even for use in a zfs context. What lld does on zfs after a given version is: "/usr/local/llvm50/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.= so.1 --hash-style=3Dboth --enable-new-dtags -o a.out /usr/lib/crt1.o /usr/lib/cr= ti.o /usr/lib/crtbegin.o -L/usr/lib /tmp/exception_test-baadc9.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-ne= eded /usr/lib/crtend.o /usr/lib/crtn.o /usr/local/llvm50/bin/ld: error: cannot open output file a.out: Invalid argument clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation) At soem point this will apply to 11.x instead of just 12.0. (I've not been tracking 11.x and so do not know the status of zfs and fallocate there.) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Nov 10 08:46:10 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 BDD06E685CC for ; Fri, 10 Nov 2017 08:46:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-154.reflexion.net [208.70.210.154]) (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 705FD6B6A6 for ; Fri, 10 Nov 2017 08:46:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30698 invoked from network); 10 Nov 2017 08:46:03 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 10 Nov 2017 08:46:03 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Fri, 10 Nov 2017 03:46:03 -0500 (EST) Received: (qmail 13651 invoked from network); 10 Nov 2017 08:46:03 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 10 Nov 2017 08:46:03 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A3860EC8983; Fri, 10 Nov 2017 00:46:02 -0800 (PST) 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: -r325627 of head: mergemaster: Creating objdir after objdir after . . . Message-Id: Date: Fri, 10 Nov 2017 00:46:02 -0800 To: Bryan Drewery , FreeBSD Toolchain , FreeBSD Current X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 08:46:10 -0000 When I use the command: ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh = -FUPi -D/mnt based on: # more = ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh kldload -n filemon && \ script = ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_clang-a= arch64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch= 64-host" \ mergemaster -A aarch64 $* in a context where /usr/obj/usr does not exist (no local build tree present at the time), I get: Script started, output file is = /root/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_cla= ng-aarch64-host-2017-11-09:23:57:04 *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...] [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental...] [Creating nested objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental/filesystem...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...] [Creating nested objdir = /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...] [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias...] . . . (long list) . . . [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd...] [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_cli...] [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_events...] So a /usr/obj/usr/src/arm64.aarch64/ directory tree ends up being created. (MAKEOBJDIRPREFIX=3D does control the path-prefix used if specified in the env list before mergemaster.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Nov 10 15:52:36 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EC4FE70DEB; Fri, 10 Nov 2017 15:52:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6D7D278CF9; Fri, 10 Nov 2017 15:52:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 8D9091ADAC; Fri, 10 Nov 2017 15:52:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 7FD957073; Fri, 10 Nov 2017 15:52:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id W9VvecgJptH3; Fri, 10 Nov 2017 15:52:27 +0000 (UTC) Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 05AD4706A To: Mark Millard , FreeBSD Toolchain , FreeBSD Current References: From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> Date: Fri, 10 Nov 2017 07:52:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Ho31eWidGbWqHKU6V3GRDVWjWiSBAKD4" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 15:52:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3Ho31eWidGbWqHKU6V3GRDVWjWiSBAKD4 Content-Type: multipart/mixed; boundary="OD0pPGqSOGApu1FIkJFGfIA26k9XCHqOp"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain , FreeBSD Current Message-ID: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . References: In-Reply-To: --OD0pPGqSOGApu1FIkJFGfIA26k9XCHqOp Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/10/2017 12:46 AM, Mark Millard wrote: > When I use the command: >=20 > ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh = -FUPi -D/mnt >=20 > based on: >=20 > # more ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-h= ost.sh > kldload -n filemon && \ > script ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstr= ap_clang-aarch64-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" S= RC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch= 64-host" \ > mergemaster -A aarch64 $* >=20 > in a context where /usr/obj/usr does not exist > (no local build tree present at the time), I get: >=20 > Script started, output file is /root/sys_typescripts/typescript_mergema= ster_cortexA53_clang_bootstrap_clang-aarch64-host-2017-11-09:23:57:04 >=20 > *** Creating the temporary root environment in /var/tmp/temproot > *** /var/tmp/temproot ready for use > *** Creating and populating directory structure in /var/tmp/temproot >=20 > [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental.= =2E.] > [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++experi= mental/filesystem...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...] > [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys..= =2E] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias..= =2E] > . . . (long list) . . . > [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd...= ] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_cl= i...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_event= s...] >=20 >=20 >=20 > So a /usr/obj/usr/src/arm64.aarch64/ directory tree > ends up being created. Hah, not what we want. I'll fix that. However from reading mergemaster.sh it seems that _at least_ /usr/obj/usr/src/etc/sendmail would be created before my changes. Can someone confirm that on stable/ or something? >=20 > (MAKEOBJDIRPREFIX=3D does control the path-prefix used > if specified in the env list before mergemaster.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 --=20 Regards, Bryan Drewery --OD0pPGqSOGApu1FIkJFGfIA26k9XCHqOp-- --3Ho31eWidGbWqHKU6V3GRDVWjWiSBAKD4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJaBcstAAoJEDXXcbtuRpfPcRoIALqs3TGgrXuyZgR7ni5YvU8H Yn1QGXBLtaIhgLwvk3XLRwMyK+FPxYLwCkPrTRvpjlkrQKc523Q8BH3Jy+i+DBQ0 OXEy8X085ZQlIDCFTesinKuKLmpvj6/NTUn+NcmWJMElSlgRVIhEHn0Y3W64Tk19 hUMBca5MpjPy4oSxD/8m0mXlbk4me0pjRDhrpPecelFrHVQzQ8d/5it+SUTFyR2u 6N7UPO3zezV19HWEzYeIQdagOgqx75Q3m7gakoj0rR591NaKpnrDn+PwEbK00YJ0 LYvQLRJiOaLnSE6277uYFl2q97bJ7km9pe1YhAlHJRg8MZNSC4AA1nMb3AH7/rA= =tNbe -----END PGP SIGNATURE----- --3Ho31eWidGbWqHKU6V3GRDVWjWiSBAKD4-- From owner-freebsd-toolchain@freebsd.org Fri Nov 10 16:30:50 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 E51F2E716AC; Fri, 10 Nov 2017 16:30:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B462079D3D; Fri, 10 Nov 2017 16:30:50 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id DEA3C1B525; Fri, 10 Nov 2017 16:30:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 24DF47194; Fri, 10 Nov 2017 16:30:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 4Etdj2ULEGLZ; Fri, 10 Nov 2017 16:30:46 +0000 (UTC) Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com A2731718D From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain , FreeBSD Current References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> Organization: FreeBSD Message-ID: <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> Date: Fri, 10 Nov 2017 08:30:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wbTlLrmbBRNXjxhcFX9QbfqT988LeOhSe" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:30:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wbTlLrmbBRNXjxhcFX9QbfqT988LeOhSe Content-Type: multipart/mixed; boundary="Unle8nFGCu9nILJbID5PEaeb0NHXs5UGw"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain , FreeBSD Current Message-ID: <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> In-Reply-To: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> --Unle8nFGCu9nILJbID5PEaeb0NHXs5UGw Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/10/17 7:52 AM, Bryan Drewery wrote: > On 11/10/2017 12:46 AM, Mark Millard wrote: >> When I use the command: >> >> ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh= -FUPi -D/mnt >> >> based on: >> >> # more ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-= host.sh >> kldload -n filemon && \ >> script ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootst= rap_clang-aarch64-host-$(date +%Y-%m-%d:%H:%M:%S) \ >> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarc= h64-host" \ >> mergemaster -A aarch64 $* >> >> in a context where /usr/obj/usr does not exist >> (no local build tree present at the time), I get: >> >> Script started, output file is /root/sys_typescripts/typescript_mergem= aster_cortexA53_clang_bootstrap_clang-aarch64-host-2017-11-09:23:57:04 >> >> *** Creating the temporary root environment in /var/tmp/temproot >> *** /var/tmp/temproot ready for use >> *** Creating and populating directory structure in /var/tmp/temproot >> >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...]= >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...]= >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental= =2E..] >> [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++exper= imental/filesystem...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...] >> [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys.= =2E.] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias.= =2E.] >> . . . (long list) . . . >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd..= =2E] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_c= li...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_even= ts...] >> >> >> >> So a /usr/obj/usr/src/arm64.aarch64/ directory tree >> ends up being created. >=20 > Hah, not what we want. I'll fix that. >=20 In fact it's similar to my META_MODE whitelist in the top-level Makefile. There's quite a few targets we don't care for AUTO_OBJ on, like distribute*, installworld, installkernel, etc. > However from reading mergemaster.sh it seems that _at least_ > /usr/obj/usr/src/etc/sendmail would be created before my changes. Can > someone confirm that on stable/ or something? >=20 >> >> (MAKEOBJDIRPREFIX=3D does control the path-prefix used >> if specified in the env list before mergemaster.) >> >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >> >=20 >=20 --=20 Regards, Bryan Drewery --Unle8nFGCu9nILJbID5PEaeb0NHXs5UGw-- --wbTlLrmbBRNXjxhcFX9QbfqT988LeOhSe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEE+Rc8ssOq6npcih8JNddxu25Gl88FAloF1DQACgkQNddxu25G l88j7Qf+IJnj0yAJroyYk2tVth66huntNnEGVYRgGNe4NKfps9EMVsDv4Mn69W23 sUqggoYCwhqb0AcRhGBz8mkrXlAw2zzNMhrw196NqLy+c8yt0dpdZwIT/n451T4j kw+E33524lvxd4xjVZ7ErrNDhJX/2YtJ+L2glE4Zm+Ij6vZI5GClfrWO7cOwJ4mU GwkhzVvizqR0/5/W6Dlq1O12sNNoq0spd3VRV4pjm9ebNblvaWdptCZhy6WMz74q C0hHpvGzOKTKJ033oQqhA+tWy9NK4OjpyosZJcFRZnn22w/QgG4bM9CyXWGwxH1E k3FtVvjo980W+LXHaEqUkkjOrX8YLg== =HjO7 -----END PGP SIGNATURE----- --wbTlLrmbBRNXjxhcFX9QbfqT988LeOhSe-- From owner-freebsd-toolchain@freebsd.org Fri Nov 10 19:54:19 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 E15FFE4ECB5; Fri, 10 Nov 2017 19:54:19 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B332A1318; Fri, 10 Nov 2017 19:54:19 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id D3A551EBDC; Fri, 10 Nov 2017 19:54:18 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id C270D75AD; Fri, 10 Nov 2017 19:54:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id W09i7zewJAV5; Fri, 10 Nov 2017 19:54:15 +0000 (UTC) Subject: Re: native-xtools gcc archs broken DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com C59F675A8 To: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org References: <7bc32cab-24e9-1a05-34e2-3f006918e4ab@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Fri, 10 Nov 2017 11:53:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <7bc32cab-24e9-1a05-34e2-3f006918e4ab@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7avMIMDJ8gbXfmwMm8qM6QiDxFGSuRJVM" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 19:54:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7avMIMDJ8gbXfmwMm8qM6QiDxFGSuRJVM Content-Type: multipart/mixed; boundary="rVS9vqPwFtqr01BsAklcLTwRBqoPOHDls"; protected-headers="v1" From: Bryan Drewery To: FreeBSD CURRENT , freebsd-toolchain@FreeBSD.org Message-ID: Subject: Re: native-xtools gcc archs broken References: <7bc32cab-24e9-1a05-34e2-3f006918e4ab@FreeBSD.org> In-Reply-To: <7bc32cab-24e9-1a05-34e2-3f006918e4ab@FreeBSD.org> --rVS9vqPwFtqr01BsAklcLTwRBqoPOHDls Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/7/2017 10:18 AM, Bryan Drewery wrote: > My recent native-xtools rewrite works fine for clang archs but not GCC > archs. I am working on a fix. >=20 Fixed in r325673. --=20 Regards, Bryan Drewery --rVS9vqPwFtqr01BsAklcLTwRBqoPOHDls-- --7avMIMDJ8gbXfmwMm8qM6QiDxFGSuRJVM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJaBgPVAAoJEDXXcbtuRpfPjDgIAKqxgU1heB7ySbXKJBAj7c0H Qz7cPNSLNtRb29Tzn/Gy2U779Tyym569nLY64Dn3cfbDbphG8kkbzBnqvUpkh2NV 14NXCH+W3kqd5KqGHoqTLwHEYNSxEadXPlCn9FK1778cYpSXoaRtZ1P3/JOxKI2I 4g1y6ob1S1AgE1MkiM6znIGQ9JGPpKyuRoeBqJqBB6SZ0ETWGtlAR11K9i87yaMy ZCt9PNGBoABPETIjOcZmwdXuFPHiGr38wvM6x3+Sk89CUOEsN88tXes8cmMmzkH+ oi3PMMcuyo0Sn9BRYqDZc0TvaE9ugFKZsoPKe6iIITo5WEv+gwq/Gtu8YW1aDH0= =blJK -----END PGP SIGNATURE----- --7avMIMDJ8gbXfmwMm8qM6QiDxFGSuRJVM-- From owner-freebsd-toolchain@freebsd.org Fri Nov 10 22:32:57 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 AB449E52A8B for ; Fri, 10 Nov 2017 22:32:57 +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 986016666E for ; Fri, 10 Nov 2017 22:32:57 +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 vAAMWvgm066277 for ; Fri, 10 Nov 2017 22:32:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Fri, 10 Nov 2017 22:32:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com 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: Fri, 10 Nov 2017 22:32:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #8 from sid@bsdmail.com --- Whenever installing world with clang from ports, the error message /usr/local/bin/clang40: basename: not found /usr/local/bin/clang40: /usr/local/llvm40/bin/:Permission denied would pop up, and a back up kernel has to be chosen to reboot. Rebuilding t= he kernel again, fixes that. (This has always been an issue with llvm40 and ll= vm50 from ports) Now I will try this, hoping it will take care of when the compiler looks fo= r a specific file or permission: CC=3D /usr/local/llvm40/bin/clang XCC=3D /usr/local/llvm40/bin/clang CXX=3D /usr/local/llvm40/bin/clang++ XCXX=3D /usr/local/llvm40/bin/clang++ CPP=3D /usr/local/llvm40/bin/clang-cpp XCPP=3D /usr/local/llvm40/bin/clang-cpp COMPILER_TYPE=3D clang X_COMPILER_TYPE=3Dclang CROSS_BINUTILS_PREFIX=3D/var/empty LD=3D /usr/local/llvm40/bin/ld.lld XLD=3D /usr/local/llvm40/bin/ld.lld NM=3D /usr/local/llvm40/bin/llvm-nm XNM=3D /usr/local/llvm40/bin/llvm-nm OBJECTDUMP=3D /usr/local/llvm40/bin/llvm-objdump XOBJECTDUMP=3D /usr/local/llvm40/bin/llvm-objdump STRINGS=3D /usr/local/llvm40/bin/llvm-strings XSTRINGS=3D /usr/local/llvm40/bin/llvm-strings This may cause a problem for when adding the filename without a full direct= ory, but it needs to be tried. XAS, XAR and XRANLIB don't work at the moment. Also, CC, XCC, and others with and without the X prefix affect the compiler= and the compiler's directory for kernel build. The X prefix seems to be supplementary for all builds: kernel, world, and ports. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Nov 11 01:08:44 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 B8C90E55ABD for ; Sat, 11 Nov 2017 01:08:44 +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 993BD6B507 for ; Sat, 11 Nov 2017 01:08:44 +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 vAB18ikv008428 for ; Sat, 11 Nov 2017 01:08:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Sat, 11 Nov 2017 01:08:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com 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: Sat, 11 Nov 2017 01:08:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #9 from sid@bsdmail.com --- This error message: /usr/local/bin/clang40: basename: not found /usr/local/bin/clang40: /usr/local/llvm40/bin/:Permission denied went away by using these settings for compiling and installing world (and kernel): CC=3D /usr/local/llvm40/bin/clang XCC=3D /usr/local/llvm40/bin/clang CXX=3D /usr/local/llvm40/bin/clang++ XCXX=3D /usr/local/llvm40/bin/clang++ CPP=3D /usr/local/llvm40/bin/clang-cpp XCPP=3D /usr/local/llvm40/bin/clang-cpp Still, after rebuilding kernel and world together, I had to use a backup ke= rnel to boot, then recompile the kernel again. This part, I believe this is an e= rror specific to my settings, and not a bug. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Nov 11 01:16: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 23AD3E56318; Sat, 11 Nov 2017 01:16:22 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E387C6C122; Sat, 11 Nov 2017 01:16:21 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id AAC7E43C6; Sat, 11 Nov 2017 01:16:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 9DF187F45; Sat, 11 Nov 2017 01:16:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id Zr17VFtRALWA; Sat, 11 Nov 2017 01:16:15 +0000 (UTC) Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 3DB1C7F40 From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain , FreeBSD Current References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <0c9c20c2-1d34-77e8-1620-fb99881a34d1@FreeBSD.org> Date: Fri, 10 Nov 2017 17:16:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rKES1NqU7ENiQCo16m3pfMTPtTUFC3a38" 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, 11 Nov 2017 01:16:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rKES1NqU7ENiQCo16m3pfMTPtTUFC3a38 Content-Type: multipart/mixed; boundary="M3GtqRvSta1otBXRB7wr6oPL81r2kH2ow"; protected-headers="v1" From: Bryan Drewery To: Mark Millard , FreeBSD Toolchain , FreeBSD Current Message-ID: <0c9c20c2-1d34-77e8-1620-fb99881a34d1@FreeBSD.org> Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> In-Reply-To: <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> --M3GtqRvSta1otBXRB7wr6oPL81r2kH2ow Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/10/2017 8:30 AM, Bryan Drewery wrote: > On 11/10/17 7:52 AM, Bryan Drewery wrote: >> On 11/10/2017 12:46 AM, Mark Millard wrote: >>> When I use the command: >>> >>> ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.s= h -FUPi -D/mnt >>> >>> based on: >>> >>> # more ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64= -host.sh >>> kldload -n filemon && \ >>> script ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_boots= trap_clang-aarch64-host-$(date +%Y-%m-%d:%H:%M:%S) \ >>> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null"= SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aar= ch64-host" \ >>> mergemaster -A aarch64 $* >>> >>> in a context where /usr/obj/usr does not exist >>> (no local build tree present at the time), I get: >>> >>> Script started, output file is /root/sys_typescripts/typescript_merge= master_cortexA53_clang_bootstrap_clang-aarch64-host-2017-11-09:23:57:04 >>> >>> *** Creating the temporary root environment in /var/tmp/temproot >>> *** /var/tmp/temproot ready for use >>> *** Creating and populating directory structure in /var/tmp/temproot= >>> >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...= ] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...= ] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++experimenta= l...] >>> [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++expe= rimental/filesystem...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...] >>> [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys= =2E..] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias= =2E..] >>> . . . (long list) . . . >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd.= =2E.] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_= cli...] >>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_eve= nts...] >>> >>> >>> >>> So a /usr/obj/usr/src/arm64.aarch64/ directory tree >>> ends up being created. >> >> Hah, not what we want. I'll fix that. >> >=20 > In fact it's similar to my META_MODE whitelist in the top-level > Makefile. There's quite a few targets we don't care for AUTO_OBJ on, > like distribute*, installworld, installkernel, etc. r325697 should fix it. >=20 >> However from reading mergemaster.sh it seems that _at least_ >> /usr/obj/usr/src/etc/sendmail would be created before my changes. Can= >> someone confirm that on stable/ or something? >> >>> >>> (MAKEOBJDIRPREFIX=3D does control the path-prefix used >>> if specified in the env list before mergemaster.) >>> >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>> >> >> >=20 >=20 --=20 Regards, Bryan Drewery --M3GtqRvSta1otBXRB7wr6oPL81r2kH2ow-- --rKES1NqU7ENiQCo16m3pfMTPtTUFC3a38 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJaBk9QAAoJEDXXcbtuRpfPzh4H/j7O6S8YdpTuAaXssof8Efqd geTajmDy9K5b2MF4/anbWdeZyZtTuBfk1Z8hSLim883DNgosTQIw0N3djj7LFkkL tVVy0Z44Nqtlo8k8LzvvRa3cQ7gxXehsTyARLSXaVxtP4VAQmliVjxl7PcxdvVr/ bHKp3fUeyi1rYXWE0JltaL1dba/u1nvR6VWMmoHeloHP2JdD3Kx5vvAXC7rCTGHV eGhS7tyte0TXMqa118AAXPW9s/RBAsU7pFt0T4SlzdpRdmV0kutvKUGohiqayfZX qDHpoAXoHNKdHNUWGa6Sc3uIumVwAyREoqnwa16tZpEF0srPzgt1Yr92o0XpJv8= =Rr2R -----END PGP SIGNATURE----- --rKES1NqU7ENiQCo16m3pfMTPtTUFC3a38-- From owner-freebsd-toolchain@freebsd.org Sat Nov 11 01:34:15 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 9F7FDE57308 for ; Sat, 11 Nov 2017 01:34:15 +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 8CE1F6CCB5 for ; Sat, 11 Nov 2017 01:34:15 +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 vAB1YFOi073133 for ; Sat, 11 Nov 2017 01:34:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Sat, 11 Nov 2017 01:34:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markmi@dsl-only.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 01:34:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #10 from Mark Millard --- (In reply to sid from comment #9) What happens if you comment out as below: CC=3D /usr/local/llvm40/bin/clang #XCC=3D /usr/local/llvm40/bin/clang CXX=3D /usr/local/llvm40/bin/clang++ #XCXX=3D /usr/local/llvm40/bin/clang++ CPP=3D /usr/local/llvm40/bin/clang-cpp #XCPP=3D /usr/local/llvm40/bin/clang-cpp I expect that it would have the same behavior: absent explicit X?? assignments the ?? assignments are copied into the internal X??'s before those X??'s are used. The same sort of point should apply to AR vs. XAR and the like if they are similarly duplicates by content. You should only needed X?? when you assign a distinct value from the matching ?? . That can cut down on the amount of text required if you care (presuming the test goes as I expect). I do not see any information for me to analyze for the rebuild-kernel-twice issue. But that goes outside this Bugzilla report. I think we are nearing your being able to close this report as "not a bug", other than possibly the original wording in: https://wiki.freebsd.org/ExternalToolchain being made clearer. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Nov 11 06:39: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 D6F3BE62206 for ; Sat, 11 Nov 2017 06:39: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 C4969758AD for ; Sat, 11 Nov 2017 06:39: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 vAB6dWro057006 for ; Sat, 11 Nov 2017 06:39:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Sat, 11 Nov 2017 06:39:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com 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: Sat, 11 Nov 2017 06:39:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 --- Comment #11 from sid@bsdmail.com --- (In reply to Mark Millard from comment #10) It compiles with the X prefix left out of the compiler and utils. I believe= it will complete successfully. This bug report can be closed. As for the X compiler/utils prefix, it seems like it is made specifically for if one compiler is used on the host comput= er, while another compiler is used for another purpose, cross compiling, and not needed if there is a sole (ports/pkg) compiler. Thank you. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Nov 11 06:40:38 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 9CA19E62270 for ; Sat, 11 Nov 2017 06:40:38 +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 8A1E9758E9 for ; Sat, 11 Nov 2017 06:40:38 +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 vAB6ecX2059403 for ; Sat, 11 Nov 2017 06:40:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld Date: Sat, 11 Nov 2017 06:40:38 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sid@bsdmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Works As Intended X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.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, 11 Nov 2017 06:40:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223551 sid@bsdmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |Works As Intended --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Nov 11 08:51:16 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 01C26E6581F for ; Sat, 11 Nov 2017 08:51:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-135.reflexion.net [208.70.210.135]) (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 B8A1579B6A for ; Sat, 11 Nov 2017 08:51:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8108 invoked from network); 11 Nov 2017 08:51:08 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Nov 2017 08:51:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 11 Nov 2017 03:51:08 -0500 (EST) Received: (qmail 9227 invoked from network); 11 Nov 2017 08:51:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Nov 2017 08:51:08 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 721A1EC88A2; Sat, 11 Nov 2017 00:51:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . From: Mark Millard In-Reply-To: <0c9c20c2-1d34-77e8-1620-fb99881a34d1@FreeBSD.org> Date: Sat, 11 Nov 2017 00:51:06 -0800 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> <0c9c20c2-1d34-77e8-1620-fb99881a34d1@FreeBSD.org> To: Bryan Drewery 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, 11 Nov 2017 08:51:16 -0000 On 2017-Nov-10, at 5:16 PM, Bryan Drewery = wrote: > On 11/10/2017 8:30 AM, Bryan Drewery wrote: >> On 11/10/17 7:52 AM, Bryan Drewery wrote: >>> On 11/10/2017 12:46 AM, Mark Millard wrote: >>>> When I use the command: >>>>=20 >>>> = ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh = -FUPi -D/mnt >>>>=20 >>>> based on: >>>>=20 >>>> # more = ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh >>>> kldload -n filemon && \ >>>> script = ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_clang-a= arch64-host-$(date +%Y-%m-%d:%H:%M:%S) \ >>>> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null"= = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch= 64-host" \ >>>> mergemaster -A aarch64 $* >>>>=20 >>>> in a context where /usr/obj/usr does not exist >>>> (no local build tree present at the time), I get: >>>>=20 >>>> Script started, output file is = /root/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_cla= ng-aarch64-host-2017-11-09:23:57:04 >>>>=20 >>>> *** Creating the temporary root environment in /var/tmp/temproot >>>> *** /var/tmp/temproot ready for use >>>> *** Creating and populating directory structure in = /var/tmp/temproot >>>>=20 >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...] >>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...] >>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...] >>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental...] >>>> [Creating nested objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental/filesystem...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...] >>>> [Creating nested objdir = /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...] >>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...] >>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias...] >>>> . . . (long list) . . . >>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd...] >>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_cli...] >>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_events...] >>>>=20 >>>>=20 >>>>=20 >>>> So a /usr/obj/usr/src/arm64.aarch64/ directory tree >>>> ends up being created. >>>=20 >>> Hah, not what we want. I'll fix that. >>>=20 >>=20 >> In fact it's similar to my META_MODE whitelist in the top-level >> Makefile. There's quite a few targets we don't care for AUTO_OBJ on, >> like distribute*, installworld, installkernel, etc. >=20 > r325697 should fix it. Most of the messages are gone in -r325700 . But there was: *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot [Creating objdir /usr/obj/usr/src/arm64.aarch64...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc...] [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/sendmail...] (No more objdir lines after that.) >>=20 >>> However from reading mergemaster.sh it seems that _at least_ >>> /usr/obj/usr/src/etc/sendmail would be created before my changes. = Can >>> someone confirm that on stable/ or something? >>>=20 >>>>=20 >>>> (MAKEOBJDIRPREFIX=3D does control the path-prefix used >>>> if specified in the env list before mergemaster.) >>>>=20 =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Nov 11 08:58:23 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DA55E65AC1 for ; Sat, 11 Nov 2017 08:58:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-129.reflexion.net [208.70.210.129]) (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 1E25079F5A for ; Sat, 11 Nov 2017 08:58:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31743 invoked from network); 11 Nov 2017 08:58:16 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Nov 2017 08:58:16 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 11 Nov 2017 03:58:16 -0500 (EST) Received: (qmail 3166 invoked from network); 11 Nov 2017 08:58:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Nov 2017 08:58:16 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 6E181EC88A2; Sat, 11 Nov 2017 00:58:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . From: Mark Millard In-Reply-To: Date: Sat, 11 Nov 2017 00:58:14 -0800 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> <0c9c20c2-1d34-77e8-1620-fb99881a34d1@FreeBSD.org> To: Bryan Drewery 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, 11 Nov 2017 08:58:23 -0000 =3D=3D=3D Mark Millard markmi@dsl-only.net On 2017-Nov-11, at 12:51 AM, Mark Millard = wrote: > On 2017-Nov-10, at 5:16 PM, Bryan Drewery = wrote: >=20 >> On 11/10/2017 8:30 AM, Bryan Drewery wrote: >>> On 11/10/17 7:52 AM, Bryan Drewery wrote: >>>> On 11/10/2017 12:46 AM, Mark Millard wrote: >>>>> When I use the command: >>>>>=20 >>>>> = ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh = -FUPi -D/mnt >>>>>=20 >>>>> based on: >>>>>=20 >>>>> # more = ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh >>>>> kldload -n filemon && \ >>>>> script = ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_clang-a= arch64-host-$(date +%Y-%m-%d:%H:%M:%S) \ >>>>> env __MAKE_CONF=3D"/root/src.configs/make.conf" = SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch= 64-host" \ >>>>> mergemaster -A aarch64 $* >>>>>=20 >>>>> in a context where /usr/obj/usr does not exist >>>>> (no local build tree present at the time), I get: >>>>>=20 >>>>> Script started, output file is = /root/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_cla= ng-aarch64-host-2017-11-09:23:57:04 >>>>>=20 >>>>> *** Creating the temporary root environment in /var/tmp/temproot >>>>> *** /var/tmp/temproot ready for use >>>>> *** Creating and populating directory structure in = /var/tmp/temproot >>>>>=20 >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental...] >>>>> [Creating nested objdir = /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental/filesystem...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...] >>>>> [Creating nested objdir = /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias...] >>>>> . . . (long list) . . . >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_cli...] >>>>> [Creating objdir = /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_events...] >>>>>=20 >>>>>=20 >>>>>=20 >>>>> So a /usr/obj/usr/src/arm64.aarch64/ directory tree >>>>> ends up being created. >>>>=20 >>>> Hah, not what we want. I'll fix that. >>>>=20 >>>=20 >>> In fact it's similar to my META_MODE whitelist in the top-level >>> Makefile. There's quite a few targets we don't care for AUTO_OBJ = on, >>> like distribute*, installworld, installkernel, etc. >>=20 >> r325697 should fix it. >=20 > Most of the messages are gone in -r325700 . But there was: >=20 > *** Creating the temporary root environment in /var/tmp/temproot > *** /var/tmp/temproot ready for use > *** Creating and populating directory structure in /var/tmp/temproot >=20 > [Creating objdir /usr/obj/usr/src/arm64.aarch64...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/sendmail...] >=20 > (No more objdir lines after that.) >=20 >>>=20 >>>> However from reading mergemaster.sh it seems that _at least_ >>>> /usr/obj/usr/src/etc/sendmail would be created before my changes. = Can >>>> someone confirm that on stable/ or something? >>>>=20 >>>>>=20 >>>>> (MAKEOBJDIRPREFIX=3D does control the path-prefix used >>>>> if specified in the env list before mergemaster.) >>>>>=20 FYI a check-old (with = MAKEOBJDIRPREFIX=3D"/usr/obj/cortexA53_clang/arm64.aarch64" in use) got me a: [Creating objdir = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64...] (Just the one objdir line.) /usr/obj/cortexA53_clang/ did not exist when check-old was started. So, the activity does track MAKEOBJDIRPREFIX when it is in use. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Nov 11 16:47:11 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1212DE6EF04; Sat, 11 Nov 2017 16:47:11 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFC5366458; Sat, 11 Nov 2017 16:47:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (unknown [127.0.1.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 1FDA7DA69; Sat, 11 Nov 2017 16:47:10 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 123D07A6A; Sat, 11 Nov 2017 16:47:09 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ptCWd98LVEHv; Sat, 11 Nov 2017 16:47:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 6912D7A62 Mime-Version: 1.0 (1.0) Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . From: Bryan Drewery X-Mailer: iPhone Mail (15B93) In-Reply-To: Date: Sat, 11 Nov 2017 08:47:01 -0800 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> <0c9c20c2-1d34-77e8-1620-fb99881a34d1@FreeBSD.org> To: Mark Millard 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, 11 Nov 2017 16:47:11 -0000 > On Nov 11, 2017, at 00:51, Mark Millard wrote: >=20 >> On 2017-Nov-10, at 5:16 PM, Bryan Drewery wrote= : >>=20 >>> On 11/10/2017 8:30 AM, Bryan Drewery wrote: >>>> On 11/10/17 7:52 AM, Bryan Drewery wrote: >>>>> On 11/10/2017 12:46 AM, Mark Millard wrote: >>>>> When I use the command: >>>>>=20 >>>>> ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh= -FUPi -D/mnt >>>>>=20 >>>>> based on: >>>>>=20 >>>>> # more ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-= host.sh >>>>> kldload -n filemon && \ >>>>> script ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootst= rap_clang-aarch64-host-$(date +%Y-%m-%d:%H:%M:%S) \ >>>>> env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" S= RC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-= host" \ >>>>> mergemaster -A aarch64 $* >>>>>=20 >>>>> in a context where /usr/obj/usr does not exist >>>>> (no local build tree present at the time), I get: >>>>>=20 >>>>> Script started, output file is /root/sys_typescripts/typescript_mergem= aster_cortexA53_clang_bootstrap_clang-aarch64-host-2017-11-09:23:57:04 >>>>>=20 >>>>> *** Creating the temporary root environment in /var/tmp/temproot >>>>> *** /var/tmp/temproot ready for use >>>>> *** Creating and populating directory structure in /var/tmp/temproot >>>>>=20 >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...]= >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...]= >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental= ...] >>>>> [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++exper= imental/filesystem...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...] >>>>> [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys.= ..] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias.= ..] >>>>> . . . (long list) . . . >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd..= .] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_c= li...] >>>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_even= ts...] >>>>>=20 >>>>>=20 >>>>>=20 >>>>> So a /usr/obj/usr/src/arm64.aarch64/ directory tree >>>>> ends up being created. >>>>=20 >>>> Hah, not what we want. I'll fix that. >>>>=20 >>>=20 >>> In fact it's similar to my META_MODE whitelist in the top-level >>> Makefile. There's quite a few targets we don't care for AUTO_OBJ on, >>> like distribute*, installworld, installkernel, etc. >>=20 >> r325697 should fix it. >=20 > Most of the messages are gone in -r325700 . But there was: >=20 > *** Creating the temporary root environment in /var/tmp/temproot > *** /var/tmp/temproot ready for use > *** Creating and populating directory structure in /var/tmp/temproot >=20 > [Creating objdir /usr/obj/usr/src/arm64.aarch64...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc...] > [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/sendmail...] >=20 > (No more objdir lines after that.) Yea this is expected. Mergemaster runs =E2=80=98make obj=E2=80=99 in etc/. The top-level check-old objdir creation is unavoidable right now... you can u= se -DNO_OBJ if you want to avoid it. >=20 >>>=20 >>>> However from reading mergemaster.sh it seems that _at least_ >>>> /usr/obj/usr/src/etc/sendmail would be created before my changes. Can >>>> someone confirm that on stable/ or something? >>>>=20 >>>>>=20 >>>>> (MAKEOBJDIRPREFIX=3D does control the path-prefix used >>>>> if specified in the env list before mergemaster.) >>>>>=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 From owner-freebsd-toolchain@freebsd.org Sat Nov 11 22:51:49 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A51FE4E86D for ; Sat, 11 Nov 2017 22:51:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-142.reflexion.net [208.70.210.142]) (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 4B9BF71BF9 for ; Sat, 11 Nov 2017 22:51:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8597 invoked from network); 11 Nov 2017 22:25:07 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 11 Nov 2017 22:25:07 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 11 Nov 2017 17:25:07 -0500 (EST) Received: (qmail 6534 invoked from network); 11 Nov 2017 22:25:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Nov 2017 22:25:07 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 00BCDEC7925; Sat, 11 Nov 2017 14:25:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: -r325627 of head: mergemaster: Creating objdir after objdir after . . . From: Mark Millard In-Reply-To: Date: Sat, 11 Nov 2017 14:25:06 -0800 Cc: FreeBSD Toolchain , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <08a57ee2-ae3e-b8ea-73a3-b6533b0fd206@FreeBSD.org> <202f44cb-39d6-99af-9804-582825ae5c07@FreeBSD.org> <0c9c20c2-1d34-77e8-1620-fb99881a34d1@FreeBSD.org> To: Bryan Drewery 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, 11 Nov 2017 22:51:49 -0000 On 2017-Nov-11, at 8:47 AM, Bryan Drewery wrote: >> On Nov 11, 2017, at 00:51, Mark Millard wrote: >>=20 >>> On 2017-Nov-10, at 5:16 PM, Bryan Drewery = wrote: >>>=20 >>>> On 11/10/2017 8:30 AM, Bryan Drewery wrote: >>>> . . .=20 >>>> In fact it's similar to my META_MODE whitelist in the top-level >>>> Makefile. There's quite a few targets we don't care for AUTO_OBJ = on, >>>> like distribute*, installworld, installkernel, etc. >>>=20 >>> r325697 should fix it. >>=20 >> Most of the messages are gone in -r325700 . But there was: >>=20 >> *** Creating the temporary root environment in /var/tmp/temproot >> *** /var/tmp/temproot ready for use >> *** Creating and populating directory structure in /var/tmp/temproot >>=20 >> [Creating objdir /usr/obj/usr/src/arm64.aarch64...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc...] >> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/sendmail...] >>=20 >> (No more objdir lines after that.) >=20 > Yea this is expected. Mergemaster runs =E2=80=98make obj=E2=80=99 in = etc/. Hmm. I looking I see the: ${MM_MAKE} _obj SUBDIR_OVERRIDE=3Detc >/dev/null && ${MM_MAKE} everything SUBDIR_OVERRIDE=3Detc >/dev/null && Its too bad that the mergemaster man page makes no reference to depending on MAKEOBJDIRPREFIX (or its default) and the tree contents that it points to. If one has more than one tree around then one should be picking the right one --but nothing in the man page suggests that. It also would not play well with not having that build tree available at the time of a mergemaster. The 20130425 UPDATING entry does note use of MAKEOBJDIRPREFIX. It notes that mergemaster makes use of the specific, bootstrapped mtree and install. Does that mean that a cross-build needs mergemaster to be executed on the cross-build host instead of on the target system? I do not see the man page as well-covering such questions for the proper usage technique. Dependency on /usr/src (by default or an alternate via -m) is clear from the man page. So, having a proper vintage of such and having mergemaster use it was clear. But such seems to not be sufficient, which was not clear. > The top-level check-old objdir creation is unavoidable right now... = you can use -DNO_OBJ if you want to avoid it. >=20 >>=20 >>>>=20 >>>>> However from reading mergemaster.sh it seems that _at least_ >>>>> /usr/obj/usr/src/etc/sendmail would be created before my changes. = Can >>>>> someone confirm that on stable/ or something? >>>>>=20 >>>>>>=20 >>>>>> (MAKEOBJDIRPREFIX=3D does control the path-prefix used >>>>>> if specified in the env list before mergemaster.) >>>>>>=20 >>=20 =3D=3D=3D Mark Millard markmi at dsl-only.net