From owner-freebsd-hackers@freebsd.org Mon Aug 10 05:11:46 2015 Return-Path: Delivered-To: freebsd-hackers@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 CDD5099D88C for ; Mon, 10 Aug 2015 05:11:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 933F134D; Mon, 10 Aug 2015 05:11:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbpg9 with SMTP id pg9so62407744igb.0; Sun, 09 Aug 2015 22:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p6AKpmpQlI151U09Ih63xLb9RkCkD50yR+rBicGWrmQ=; b=zIOyzxDjKby9JsUMdfxkRt6AA2jCip3xHC6Z76ppLCNA5TiSI/cwzJCn1F4/OV2OG7 ZsjGWbBwenM1vcmdb+lIzk6ly8R/4doHGYzpGGLp1Om0AU6GIHzKEuPn4p0+O6Y/y+Ff TffcF/g9ALW+rc9BC6UMdvQRpnSVd6GtdTZRAm0WYlNSxPFRHRQyPSrusFnvsPFfSqnr 2HhoxzsYGUvTXnzJTtzj/bITphB4nlYc1GToD6je6YBUL4xqTXxw1YxqyOgFlavM4X4o Mq1/tu8WXN8pf5+JyINSj9aqcLAtcx60VJzkL6z2zpvYpW+AGWi8SZgCVQwjOesP3b1Y /kVg== MIME-Version: 1.0 X-Received: by 10.50.142.69 with SMTP id ru5mr8690785igb.61.1439183505969; Sun, 09 Aug 2015 22:11:45 -0700 (PDT) Received: by 10.36.38.133 with HTTP; Sun, 9 Aug 2015 22:11:45 -0700 (PDT) In-Reply-To: <926DDA42-8883-4AB4-B229-D44387FF5C6B@me.com> References: <20150809215403.GC20238@server.rulingia.com> <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> <51EEBC6E-5D85-439D-874D-D223EE045515@me.com> <926DDA42-8883-4AB4-B229-D44387FF5C6B@me.com> Date: Sun, 9 Aug 2015 22:11:45 -0700 Message-ID: Subject: Re: Sparc64 support From: Adrian Chadd To: Jordan Hubbard Cc: Bill Sorenson , "freebsd-hackers@freebsd.org" , Kevin Bowling , "K. Macy" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 10 Aug 2015 11:21:40 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 05:11:46 -0000 On 9 August 2015 at 21:34, Jordan Hubbard wrote: > >> On Aug 9, 2015, at 8:48 PM, Adrian Chadd wrote: >> >> What's missing is someone funding / finishing the push to external >> toolchain support for all platforms. > > Does someone have that condensed down to a set of bullet points? Which p= latforms are mandatory and which are optional? Is the task considered done= when one can do: > > # cd /usr/src > # make buildworld buildkernel USE_EXT_TOOLCHAIN=3Dyes EXT_TOOLCHAIN_PORT= =3Dgcc-4.9 (or whatever the suitable incantation is?) > > Does it have to work for multiple values of =E2=80=9Cexternal toolchain= =E2=80=9D? Is it a safe assumption to just say that =E2=80=9Cport install = FOO=E2=80=9D will be a sufficient prerequisite and /usr/local/bin/cc is all= one needs to reference as the right compiler driver (for the C stuff obvio= usly). > > If anyone is going to fund anything, they will want a very specific set o= f deliverables to fund, since it=E2=80=99s otherwise kind of a blank check = with a completely arbitrary outcome. It's supposed to be (for mips): pkg install mips-gcc mips-xtoolchain make ... CROSS_TOOLCHAIN=3Dmips-gcc ... .. however there are loose ends to fix that prevent that from working out of the box. There's also some way involving "X" variables that one can use to point tools and such at non-system-default versions of things, but it's not nicely wrapped up as CROSS_TOOLCHAIN is, and I don't believe it's authoritatively documented (eg in a manpage, or share/examples/.) I get slightly different versions of slightly different things from different people each time I ask. >> What's also missing a little bit here is the tier-1-ness of the >> external toolchain support by the people using/developing other >> toolchains. > > Not sure what that means? The clang folk (eg dim) didn't use the external toolchain stuff the last time I checked. They would create a new branch and import clang into freebsd in it, or just extract it over the top of a freebsd checkout. Ie, the folk that would be the #1 testers and consumers of this stuff don't use it. I don't know if they still do it - we should ask. >> It's basically there. There are some rough edges, but since the >> compiler-developer people aren't using it and the non-x86-building >> people aren't being forced to use it, the development inches along >> very slowly. > > Again, maybe you could qualify just what that means. I don=E2=80=99t kno= w what moving parts are even really being described here. My life is clang= / LLVM and has been for a very long time - I don=E2=80=99t even know what = gcc is anymore. :) See above. :) >> If you'd like to erm, "rush" this along, we should actively start the >> "deorbit gcc-4.2 by freebsd-11" and "disconnect gcc-4.2 from the -head >> build" movement now, get those bits done, and start arm-twisting to >> get the last bits finished. > > If gcc 4.2 de-orbits then that means that clang / LLVM can take its place= as the =E2=80=9Cdefault toolchain=E2=80=9D in base and any other value of = GCC (which?) comes from ports? Right - for those ports that don't currently 'work' stable on clang/llvm, they'd just fail to build unless one defined an external or cross compiler toolchain. -adrian