Date: Sun, 9 Aug 2015 22:11:45 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Jordan Hubbard <jordanhubbard@me.com> Cc: Bill Sorenson <instructionset@gmail.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Kevin Bowling <kevin.bowling@kev009.com>, "K. Macy" <kmacy@freebsd.org> Subject: Re: Sparc64 support Message-ID: <CAJ-VmokHCW8MawfVC_1z2SZ7hfX4wXBqNoGPHQQxya2rV%2B1QMw@mail.gmail.com> In-Reply-To: <926DDA42-8883-4AB4-B229-D44387FF5C6B@me.com> References: <CACcTwYmS1c5uoO-WiJQDwgqYAevX7WZ7ZrP297hnOu7cNET3CA@mail.gmail.com> <mq3sg1$bno$1@ger.gmane.org> <CACcTwYnU=E-6sV3yLh3yKUSPZOg7967XV5ToXoSVPuNfOjF7hQ@mail.gmail.com> <CAHM0Q_NEYWxpHCwEdytfY6i9%2BRO2BebezzmenfQ_1c4u7zGrgg@mail.gmail.com> <CACcTwY=DcUREt5nJWo_eJfrB=3sQXBaS6nc%2B07fpZhxARD0zTQ@mail.gmail.com> <20150809215403.GC20238@server.rulingia.com> <6C12EBFE-EAA9-4C12-9F03-1CB2C28C4A6E@me.com> <CACcTwYktQRTqVSr7PRr5huwbVXVu6oCy26TKiAxzf2NiGAcocA@mail.gmail.com> <51EEBC6E-5D85-439D-874D-D223EE045515@me.com> <CAJ-VmomzV0YKQwenwSZv6fMAOUP8TmPs-oyQaM8KTF7Ndhv_%2Bw@mail.gmail.com> <926DDA42-8883-4AB4-B229-D44387FF5C6B@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 August 2015 at 21:34, Jordan Hubbard <jordanhubbard@me.com> wrote: > >> On Aug 9, 2015, at 8:48 PM, Adrian Chadd <adrian.chadd@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokHCW8MawfVC_1z2SZ7hfX4wXBqNoGPHQQxya2rV%2B1QMw>